I've fallen to it myself, but mostly to the reverse version of it : not saying "this feature is obviously required" and then when learning that my favorite tool (shell, text editor, language, web browser, version control, whatever) doesn't have it saying "oh but it's useless", but the reverse : someone tells me "you should try tool X, it has that great feature" and then I answer "I don't see the point of that feature, it's just that your tool X is bloatware, I'll still to my tool Y" and when a later version of my tool Y implements the said feature I then switched and said to everyone "you should use tool Y, it has that great feature".
It's very similar (and since I became aware I've a tendency to this bias, I try to force myself to not fall to it again, but not totally successfully...) but it's somehow more understandable : you very often see the point of a feature/tool/... once you started using it regularly in your own use cases.
I don't think I did the direct version of it since the time where I was a teenager. At least, I hope I didn't...
I've read that people only use small subsets of the available features in huge programs such as Microsoft Word, so it would seem like they should be able to get rid of "all those features nobody uses" and make a version without all that complicated bloat that confuses everyone. The problem, however, is that everyone uses a different subset of the feature set, so one person's useless bloat is someone else's essential, obvious feature that they don't know how people would get along without.
"Features seem useless until you get used to them, at which point they become essential" may be a fairly common pattern...
Follow-up to Journal article about politics and mindkilling. That post showed that people can be convinced that a view is correct by being told that their political party endorses it, even if their party actually opposes it. A similar, but stranger, effect, is that people can be convinced that a view is correct because their favorite software implements it - even if they have stated that the view is wrong just minutes ago.
Subversion is a popular version-control system used by software developers. The "repository" is where subversion stores the definitive copy of each file it is keeping track of. A "diff" is when you ask subversion to show you all differences between your new code, and the last version of that code that it knows was in the repository. A "tag" is when you associate a set of versions of different files together, in a way so that they can be easily compared against or reverted to, without creating something called a "branch".
I've had variants of this conversation about Subversion three times so far:
Me: [problem X] happened because Subversion doesn't let you diff against the repository.
Other: What?
Me: Subversion doesn't let you diff against the repository. It only diffs against its local copy of the repository, which it updates when you do a checkout, commit, or update. So it won't show you any changes that someone else has made to the code since then. You can never see what changes other people have made since your last commit, because to get the changes, you have to do an update; and the changes are added to your code without being shown to you, and a diff won't show them. So you just cross your fingers and hope their changes are compatible with yours.
Other: That's ridiculous! Subversion doesn't do that. That would defeat the whole purpose of version control. That would be idiotic.
Me: Really, it does that. I've tried it. Repeatedly. I've wasted days of work because of it.
Other: Nonsense. Of COURSE Subversion diffs against the repository.
Me: Try this: Create a new file foo in your checkout in directory X. Then svn add foo and svn commit foo. Check out the same repository in directory Y. Modify foo in directory X. svn commit foo. Then do an svn diff foo from directory Y.
[A few minutes later, after trying it:]
Other: Well, of COURSE Subversion doesn't diff against the repository. It's meant for large, distributed projects. You wouldn't want to have to do diffs over the web.
Me: Why?
Other: It would be too slow.
Me: You do checkouts and commits and updates over the web. Are they too slow?
Other: You want to diff against your previous version. It would be too confusing to see the changes other people have made, too.
Me: Three minutes ago you said it would be idiotic not to diff against the repository.
Other: Look, Subversion is an industry standard!
Me: Subversion doesn't even let you tag releases.
Other: Of COURSE Subversion lets you tag releases.
[Conversation eventually ends with Other explaining why you don't need to tag releases anyway.]
[P.S. - There is a very long syntax for svn diff that lets you specify full paths to the repository and your checkout directory. It can't mix paths and URLs, so you have to specify your checkout directory as a complete URL. No one that I know uses this syntax.]