In my organization, this has resulted in the usability-inclined testers hammering hard on even 'normal' Linux operations, causing them to fall out of the Linux idiom -- were are talking about fear of editing text files, fear of RPM's with dependancies, etc -- while this is just an education issue, it's another example of user-friendliness being taken to areas where it is not required (in this case, Linux servers and system administrator tasks). The result is that our Linux apps probably offend hardcore Linux users by trying to do things the wrong way. For instance, our command lines are way too verbose and usually have too many prompts and too much output.
In general, though, I'll say usability is a very good thing for end users...but part of the reason I like Linux is that it *encourages* tinkering under the hood.
As an analogy, suppose Linux is a car and your program is the engine. If you take it apart and reassemble it incorrectly (for example: say you borked a config file), the Linux idiom says this is *your fault*, while the Windows idiom says the you should never have been able to do this in the first place.
The HTML interface versus program GUI interface is a similar issue. Different people think usability means different things, and it always depends on who your audience is. In my case, my code is being tested by folks who like AOL-like interfaces (sigh), thus one has to write Linux apps that behave like Windows apps ("Are you really really sure you want to delete that logical drive?").
Conclusion: usability is something different to everyone. Usually the person writing the requirements has the final straw. Whether the camel's back is broken depends on how much you like to do usability things -- I don't :)