This might be a good opportunity to link to 10up's Engineering Best Practices, a collection of advice & tools for writing secure, performant code for WordPress. I think there's a WordPress hosting best practices doc in the works, which will probably be coming out later this year.
The teams I work with build highly scalable WordPress sites for some pretty big clients. Your last paragraph touches on the core of the issue: by adapting version control, CI/CD servers, and so on, a lot of what makes WordPress such a powerful tool for beginners goes out the door. But, the WordPress core team pays a lot of attention to user experience, and it provides a friendly back-end for managing content. If anyone's used WordPress to post pictures of their cat or run a mommy blog, they can post to their corporate site, too. That's pretty amazing.
I don't want to pick apart the individual points of your post. There's a lot I disagree with, but that's only because I have years of experience building & hosting enterprise WordPress sites. And I don't think the community does enough to spread this essential knowledge. Our documentation, our conferences…so many things are geared toward absolute beginners. I'm giving a talk on Functional Programming for WordPress developers at WordCamp Boston this month. I'm kind of curious how many people are going to show up.
But I do want to address two details:
If you're managing your own server(s), don't use something like W3TC. WordPress has built-in support for something called an Object Cache, which stores query results, "transients", and other data in an in-memory store. We prefer memcached because it's mature, using Zack Tollman & 10up's plugin. On some sites we use a Redis object cache plugin because a particular host might prefer it or have the daemon running because of another site. For full-page caching, you want Batcache which stores pages in memcached. These plugins are more lightweight and better maintained than the mainsteam caching plugins, plus they let you use a shared cache server so multiple web heads can take advantage of the work the rest of the servers have already done.
Likewise, if you have multiple servers…well, first all your code should be managed in a VCS like Git, and that includes plugins & themes. Add define('DISALLOW_FILE_EDIT', true); to your wp-config.php so nobody thinks they can just install a plugin when they want to. Second, either put your wp-content/uploads directory on a shared resource (NFS or S3) so files are available to all the servers, or synchronize the files across all the servers with Unison. There's no excuse for your WordPress install's files to be different between servers for more than a few seconds.
I don't agree with your statement that "if you are professional enough to do so, you will have run away from it long time ago". WordPress is the foundation of most of the things we build. I'm seeing more & more projects from our team and others using React with WordPress's REST API. And you could argue that bolting on things like memcached, Elasticsearch, nginx microcaching and so on is just covering up the platform's weaknesses. But it also allows us to leverage its strengths as we produce modern experiences.