This is the correct way to do a lot of it. For instance, images. Yes you could optimise the things in Photoshop but actually you want your artworkers to be doing the images right, so they look good and tell the story. Optimising the images is something that should be abstracted out, so on your dev version of the site everything is in 100% glorious, maybe even phone-res megapixels.
Then, abstracted out with PageSpeed you can deliver the webp when you need to and also the source set images so every device has the right size images that update themselves automagically if people zoom in.
Same with minification, why have complex build tools when you can just have PageSpeed do it properly?
You can also have beautiful HTML for view source by putting on the right PageSpeed filters.
The list goes on, apart from the results it also does the abstraction bit, so artworkers can do their Photoshop stuff unencumbered, same for frontend and backend devs.
The thing about it though is that you need to understand a mix of different things that are nowadays split up into different job roles of ever increasing specialisation. A Photoshop person isn't going to go all command line on the server for the perfect PageSpeed Nginx setup, neither is a CSS person, a UX expert, a JS expert or a backend expert. Not even the guy who keeps the site online is going to typically step up to using Pagespeed for the benefit of the team. Pagespeed just doesn't fit into one of these niche-jobs so it is more likely to be found on smaller one-person efforts where there aren't the organisational hurdles in the way.
No you need your artworkers to do it right it the flipping first place and not place excessive load on your live environment - or make the live environment more complex than it needs to be.
Well, in reality, all of these build tools for performance are design to deploy to a "static server" which is out of the control of the developer. That is why they process the images at build time rather than "on the fly"
Not saying that Page speed is wrong, but it is a niche tool that depends on the server side implementation. Some developers prefer to abstract "the server" from their architecture...
Then, abstracted out with PageSpeed you can deliver the webp when you need to and also the source set images so every device has the right size images that update themselves automagically if people zoom in.
Same with minification, why have complex build tools when you can just have PageSpeed do it properly?
You can also have beautiful HTML for view source by putting on the right PageSpeed filters.
The list goes on, apart from the results it also does the abstraction bit, so artworkers can do their Photoshop stuff unencumbered, same for frontend and backend devs.
The thing about it though is that you need to understand a mix of different things that are nowadays split up into different job roles of ever increasing specialisation. A Photoshop person isn't going to go all command line on the server for the perfect PageSpeed Nginx setup, neither is a CSS person, a UX expert, a JS expert or a backend expert. Not even the guy who keeps the site online is going to typically step up to using Pagespeed for the benefit of the team. Pagespeed just doesn't fit into one of these niche-jobs so it is more likely to be found on smaller one-person efforts where there aren't the organisational hurdles in the way.