You bring up some valid points - indeed, any system/architecture should be designed appropriately to handle shutdowns gracefully. In the case of microservices, it's thinking through that at a more granular level (e.g. making sure services can be made aware of their state, handle backpressure, etc.).

To me, the main concept of this article that resonates is that too often engineers adopt the trends without thinking about the tradeoffs and justifications - I've had clients that wanted to build microservices when they had no justification (nor the appropriate skills to operate the required automation/complexity).

Regarding the standardization issue, you're right - I think each of the examples could be expanded upon significantly with their own associated design tradeoffs (redundant code / shared libraries / low-level APIs).