So the fallacy in the argument is that implementation details are relevant to everyone.
They aren't. They're relevant to system builders and people who like tinkering because that is a separate domain to the user domain.
Most users just want an appliance, because a good appliance - like Hypercard, Excel, and maybe VBA - allows them to concentrate on the things that interest them, not on the things that interested the appliance designer when they were building their product.
This is fine for products in the the app store - it's a mark of good design that it reveals exactly as much complexity as it needs to, but no more - but it breaks down when the user domain and the tinkerer domain overlap, as they do in professional software development.
The reason it breaks down is because there is no general solution. No library is ever going to be a perfect snap-in tool that solves your problem for you, no language is going to hide OS-level and library-level abstractions with perfect elegance, and no OS is ever going to have perfectly elegant abstractions for file and network operations, simultaneous and synchronous operations, and so on.
Everyone has opinions about how software should be designed, the problems are essentially open-ended, tinkerers have a tendency to turn everything into an excuse for tinkering instead of a streamlined product/service pipeline, and the result is the mess we have today.
And this is probably how it has to be, given the limitations of human reason.