The combination definitely seems overwhelming, but each tool is a solution to a real problem. That's where the "(real)" in the title is coming from. Yes, if you're only writing a hello world app you certainly don't need all that bloat, but if you're writing a real world app, here's a list of legitimate requirements you have to fulfill:
1. You offered your client a static page with purple background, blinking title, a guestbook and a visit counter - they miraculously refused; therefore, you need a database. That was true even in the good old days of the LAMP stack, circa the time BLINK tags went out of fashion.
2. Your app will be rather complex (many views, controllers and routes) and probably have more than one developers, and you'd want to somehow manage all of this complexity, have a standardized way of organizing views/controllers/etc. and cut down on hard-to-maintain boilerplate. That's why you want a framework.
3. Your data will change (you need migrations) and inline SQL gets hairy very quickly. You'll need an ORM. You'll need to create models/entities for that.
4. Your client demands an SPA. They want incremental search, sliders, drag and drop functionality and everything else that require a Javascript framework.
5. You need responsive design and nice looking CSS widgets, and a design that easy to update (so that you could replace your primary and highlight colors in a single place). You end up with a CSS framework like Bootstrap and a preprocessor like Sass.
6. You realize you'll end up writing JS code no less than you would write PHP, and you want to avoid callback hell, and the general weirdness that comes with classic ES5, so you go ahead and add Babel to your pipeline.
7. You also need to merge and minify JS and CSS files, so you end up tacking webpack or browserify or a custom grunt or gulp build script (or even both of them) to your pipeline. Yeah, complex pipeline suck, but in the old days we used to zip everything and upload with FTP.
8. The article doesn't mention it, but you may definitely want to set up a CI pipeline that does all of that, and link it with your Git repo using webhooks.
9. Wow, you need so many javascript and PHP libraries! Let's use a package manager.
10. Your SPA needs to communicate with your app somehow, right? We need to use an API for everything. REST is getting a lot of hate recently, but it's not like gRPC or JSON-RPC or GraphQL are simpler to set up.
We haven't even mentioned adding OAuth2 support, social login, analytics, error reporting and logging, client-side router, isomorphic apps which generate views on the server side, view caching and object caching, a separate server for static resources, load balancing, a CDN, setting up LetsEncrypt to automatically issue SSL certificates and whatnot.
Yeah, setting up a modern web app is complex. Not because this is how we do web app, but because by 2017 users' expectations of web app are much higher than they used to be. If your app is in a position to skip some of the issues listed above, by all means skip it. People often go into overkill mode with all these frameworks (one of my pet peeves at work is people using Spring for microservices).
Of course, if all you need is printing "Hello World", even good old <?php echo 'Hello, world!'; ?> is an overkill when you could just use static HTML.
Nah, it's all about http://jsonapi.org these days. GraphQL seems neat. Cap'n Proto also seems neat but I'm unaware of anything actually using it. gRPC is also neat but AFAIK not supported in a browser, so you need some kind of gateway to have it work with browser clients anyway (think SPAs calling APIs which can normally service server to server over gRPC). CPNP has the same-ish problem in that it doesn't fully work in browsers (serialization works but not RPC).
1. You offered your client a static page with purple background, blinking title, a guestbook and a visit counter - they miraculously refused; therefore, you need a database. That was true even in the good old days of the LAMP stack, circa the time BLINK tags went out of fashion.
2. Your app will be rather complex (many views, controllers and routes) and probably have more than one developers, and you'd want to somehow manage all of this complexity, have a standardized way of organizing views/controllers/etc. and cut down on hard-to-maintain boilerplate. That's why you want a framework.
3. Your data will change (you need migrations) and inline SQL gets hairy very quickly. You'll need an ORM. You'll need to create models/entities for that.
4. Your client demands an SPA. They want incremental search, sliders, drag and drop functionality and everything else that require a Javascript framework.
5. You need responsive design and nice looking CSS widgets, and a design that easy to update (so that you could replace your primary and highlight colors in a single place). You end up with a CSS framework like Bootstrap and a preprocessor like Sass.
6. You realize you'll end up writing JS code no less than you would write PHP, and you want to avoid callback hell, and the general weirdness that comes with classic ES5, so you go ahead and add Babel to your pipeline.
7. You also need to merge and minify JS and CSS files, so you end up tacking webpack or browserify or a custom grunt or gulp build script (or even both of them) to your pipeline. Yeah, complex pipeline suck, but in the old days we used to zip everything and upload with FTP.
8. The article doesn't mention it, but you may definitely want to set up a CI pipeline that does all of that, and link it with your Git repo using webhooks.
9. Wow, you need so many javascript and PHP libraries! Let's use a package manager.
10. Your SPA needs to communicate with your app somehow, right? We need to use an API for everything. REST is getting a lot of hate recently, but it's not like gRPC or JSON-RPC or GraphQL are simpler to set up.
We haven't even mentioned adding OAuth2 support, social login, analytics, error reporting and logging, client-side router, isomorphic apps which generate views on the server side, view caching and object caching, a separate server for static resources, load balancing, a CDN, setting up LetsEncrypt to automatically issue SSL certificates and whatnot.
Yeah, setting up a modern web app is complex. Not because this is how we do web app, but because by 2017 users' expectations of web app are much higher than they used to be. If your app is in a position to skip some of the issues listed above, by all means skip it. People often go into overkill mode with all these frameworks (one of my pet peeves at work is people using Spring for microservices).
Of course, if all you need is printing "Hello World", even good old <?php echo 'Hello, world!'; ?> is an overkill when you could just use static HTML.