See now, we keep assuming without evidence that the old thing is actually better.

Sometimes it's true. I don't trust myself to write a non-trivial DBMS. I reach for Postgres. And there are some things I just don't want to do - like any kind of cryptography or compression. (I also wouldn't trust myself to avoid cryptography side channels.)

But existing APIs tend to do a lot more than you want, and that brings its own bugs. Consider the sqlite WAL-reset bug that Tailscale found when it corrupted several tailnets' control plane data. They were using a separate database file per network and a custom backup system too clever for its own good. How much control plane data do they have in a network? I'd imagine under a megabyte. They could have written the entire thing in JSON and committed with an atomic rename, and not had the bug. (On the other hand they could've used a single large Postgres.) I don't fault them for the corruption as sqlite is normally extremely reliable, but it just shows how adding things to a system can make it worse.

Or any reverse proxy when you do an HTTP Request Smuggling attack. If you hadn't used a reverse proxy, you wouldn't have been vulnerable because the attack is only relevant to reverse proxies (and forward proxies). Do you need a reverse proxy? Sometimes yes but other times no. You can also prevent that attack by using SCGI, FastCGI or WSGI instead of HTTP as your backend protocol.

I bet there's at least one vulnerability caused by X-Accel-Redirect processing, too.

Remember Log4Shell? The Log4J library had too many features, and some of them could be combined in an unintended way to cause remote code execution. Code worked exactly as intended, it just had too many features. You don't want that.

Remember Heartbleed? The old "battle tested" system turned out not to be.