> Why? This answer is most common one and always puzzled me.

If you don't use it how do you know you're solving actual user problems?

I used to contribute to an OSS project and there were a lot of times where the devs and users had differing opinions on how a feature should work.

I think one reason is that if you already know a project as a user you're a long way up the learning curve for understanding it. You know roughly what its feature set is, you know how new features would fit in with the existing ones, you know how to do basic "does this thing work" testing of it. You probably have an idea of what changes are likely to be small tweaks to existing functionality and what are bigger and harder. Knowing the shape of the outside of something makes it easier to understand the inside of it. If you start out with a contribution to a project you don't use, you don't have that initial base to build on and so it's harder.

Which isn't to say it's impossible, of course -- people getting new jobs working on proprietary software have to get up to speed with programs they probably never used before. It's just time consuming. The "what should I work on?" question implies that the asker has no preference, so answers optimising for what's easier to get started with make sense.