And yet they're not mistakes. Not in the sense that you're making them to be anyway.

1. The user is an idiot

it's a correct way to describe the development attitude but the attitude in itself is not a mistake unless it results in a flat out refusal to do work.

The thing is, when working for an MVP you do need a counterpoint when assessing requests. Any feature comes at a cost and sometimes discussing whether it's stupid to entertain it is productive in the sense that it brings out arguments and in a real team that works together a developer's perspective should be heard, discussed and so on.

2. My code is art

it's not wrong view. It can be wrong to hold it as an absolute in the sense that too much time is spent chasing an elusive perfection. But code is art.

However it's important not to forget that art is and has always been utilitarian. All artists have taken their time to do commissioned for paying customers. In the 14th century a customer could wait years. Today even artists have to get their projects out ASAP or be beaten to the punch.

3. Knowing it better is a double edged sort. It's not outright wrong to use that as a reason in the sense that it helps ship faster for an MVP.

But when you say that it's a struggle to do things using X and Y is a better tool then the reason only holds water as long as "being familiar" results in being effective with it for the current task. If it's not the case then by all means learning something new can a reasonable choice if the costs are outweighed by the benefits. But if familiarity translates in a better and efficient job with X despite Y being theoretically a better tool, then it can stand to reason to still use X.

4. Yes, that's the only one I can flatly say it's a wrong attitude. It's a signal for a dysfunctional team and a symptom of ineffective communication top-down.