That's why I hate things like hackathons. We need people to think of us as engineers rather than tinkerers, and the labels we accept aren't helping.
All they see is a lightswitch that works and a phone that runs apps and makes calls.
They don't know anything about distributing power across a national power grid while minimising losses and keeping phases synchronised, metallurgy, ceramics, plastics and organic chemistry, industrial injection moulding and machining, data compression and coding, compiler design, radio frequency and microwave circuit design, microprocessor manufacture, automated assembly, adaptive digital signal processing, optoelectronics and display technologies, networking protocols - and so on.
For them it all just works, even if the software is often a bit crap.
99% of the complexity is invisible, so they have no clue it's there - and you can't value something you don't know about.
The only way I found to handle that is trying to be very careful when I feel 100% sure something is as I think it is. But sometimes you are so sure of yourself that you don't even realise that.
For the former quote I've found there to be hope, since you can engage the "it's so easy, I see how you can do it" the same way _we_ engage ourselves, making them deconstruct the problem to the end of running them into a common design issue (in my sample it was asking the PM to reason about long-horizon backfill and replay logic); it can even have a positive outcome if you explain it such that the PM gains trust in your insight, and may help to build some of that respect.
In the latter, when there is simply as you say a LACK of respect, and not just a... shall we say communication gap? Those are the situations I've seen some of the more painful PM/dev interactions and I have far less helpful advice, unfortunately, since I'll admit that the problem then resonates, as eng loses respect for PMs who don't respect them and etc etc.
Sorry for the ramble, this has been a topic I've thought about a lot WRT "implicit problems in scaling a company past a certain size"
That's my experience too. But your parenthetical remark is a very important point!
I've been in plenty of situations where an engineer cared too much about delivering 'good' work by their own definition of good, when clearly it clearly wasn't 'good' for the company/team/product. In fact, I've been that engineer myself a few times, where only in hindsight I realized that I didn't see the bigger picture.