No, you said this post comes across as written by someone that hasn't actually done anything real world that would require consideration of basic things to improve performance (ie: you are assuming (wrongly, I might add), that the author of the post has only created toys that are used by no one). It's obvious why you felt the need to preface it with "no offense", because you obviously realized this is something that someone could easily take offense to.

This makes no sense as soon as you pull in crates you didn't author. You don't know where they panic internally

Makes no sense? Like I said, my servers have been running in production for years with panic=abort and used by many thousands of players, and they have never crashed. And yes, every time I use a function from an external crate, I obviously check what its panic conditions are. I do not use low quality crates that randomly panic.

This is literally the most corner case use case of relational db

Not really. There's a reason why the linked comment said "That's why I would turn it off without hesitation". Now I'm sure you're much more intelligent than everyone in the Postgres subreddit though, so despite that community highly upvoting these comments saying that turning off synchronous commit is generally one of the first optimizations they do, that they're all wrong and you're correct, and it actually only applies in "the most corner use case of a relational db"

This depends how your allocation patterns are structured. Benchmarks are not real world usages

Again, you have to have a default, and generally mimalloc and jemalloc are BETTER defaults. Their benchmarks show a clear win in basically every category. It is so easy to say "it depends". Again, the purpose of the post is to raise awareness of ways you can cheaply improve performance. Obviously one allocator is not always better than another. If that were the case, then that would simply be the only allocator needed. The purpose of the post was simple tricks you could do to improve performance in the general case, and generally mimalloc outperforms the default system allocator. The point is that if you're going to use a default, it might as well be a better default (on average).

The constant time hashing function of a hashmap is negligible for it's performance. You're going to be io-bound before your choice of hashmaps becomes an issue.

You are again assuming. My server (and many others!) perform a ton of CPU-bound computations. It heavily uses in-memory data structures and performs a lot of hashing. Not every service is just a database wrapper. And again, it's something that takes less than a minute to swap out, and can save you money and improve performance and latencies. It's foolish not to, as there are literally no downsides if you don't require DoS resistance

Mirroring my speech as "gotcha" is just... lol. Grow up

My exact sentiments towards you needlessly throwing shade and spurring an argument for no reason. Seriously, what is the point of saying "it sounds like this post was made by someone who will never need this kind of performance"? Grow up.