So it really is that simple: a small bash script, building locally, rsync'ing the changes, and restarting the service. It's just the bare essentials of a deployment. That's how I deploy in 10 seconds.

I'm strongly opposed to local builds on any semi-important or semi-complex production product or system.

Tagged CI release builds give you a lot of important guarantees involved in release concerns.

I'll take the fresh checkout and release build time cost for those consistency and versioned source state guarantees.

Your proposed solution to overly complex systems seems to be to ignore the requirements that make them complex in the first place. If that works for you, this is a perfectly fine approach. But most companies with actual signed SLAs won't accept "we'll just have a few seconds of downtime/high latency every time a developer deploys something to production #yolo".

I'm not sure I understand the trade offs you're choosing by deploying this way. The benefit of simplicity an speed of deployment seems clear from your write-up. But are those the most important considerations? Why or why not?

this has the same logic as saying npm install takes a while so just don’t use libraries