Don't get me wrong. I use C++ almost exclusively. But I often see and have to deal with programs based on poorly designed classes built one on top of another. I also have to deal with memory fragmentation which doesn't really affect PC programmers. And not knowing when a malloc may be triggered from some overly intricate spaghetti code at the lowest level is a mine field.

Most people never have to deal with how inefficient the stdlib malloc is. I recently had to work on a project where 7000+ mallocs occured every frame. And while they mostly got away with it on a "PC" and kept a 60Hz framerate that number of mallocs took more than 1/60th of a sec on the console I was working on. That meant framerate instantly went to 1/2 and had absolutely no work accomplished to show for it. Most of it doing trivial 4 byte new's. Rewriting malloc tailored to the app helped but the entire project was riddled with poor C++ design.

People don't realize how poor their code runs unless they are forced to face the consequences of it an are too often clueless how to fix it or have progressed to the point where it's too late to fix it.

It's extremely hard to write good assembly code on virtually any system these days. Often you end up simply optimizing what the compiler put out so you don't have to spend volumes of your time trying wrap your head around re-ordering instructions and the like. And then there's PCs where you can often give no rhyme or reason as to why one piece of code runs faster than another. You can have one piece of code, smaller, aligned and with a smaller "cycle count" that runs slower than another seemingly slower piece of code. And then you have only really optimized for one particular brand and stepping of processor.