that you understand and think dropping down to C++ is what you need to do when you "need the best performance" is quite enough of a tell to invalidate the rest of your opinion here. if you "need the best performance", you need to ditch OOP and RAII, and you're probably reaching for C. Zig wants to be the better choice there. that's a perfectly reasonable niche for a language to exist in.
if you read the article carefully, jarred is pretty clear about how their specific requirements with Bun cause friction when bridging the manual memory management of Zig with a garbage collected JS runtime. at face value, that makes quite a lot of sense to me, and it's a pretty specific scenario that is not the full on condemnation of memory unsafe languages that your comment is.
It is widely accepted that you can get better performance with c++ far easier than C. Outside of custom rolling assembly , a large aspect of performance tuning is compile time optimization, which is extremely non trivial in C, while being supported in language with C++. All the things people associate with C performance can be done in C++, the converse is not true
the point of c++ when you need max perf is to be able to maintain the compile-time abstractions you need w/ templates instead of macros and undocumented optimizer behavior, not oop or raii
you're right that that is a weak argument against C++ in that use case (biased by my own dislike of the language); but it is also a niche that Zig fits into quite well. so it's weird for the OP to claim it's ok to drop down to C++ when needed while kind of suggesting they don't get why anyone would use Zig
If you are willing to hand code intrinsics it doesn't really matter what language you pick from a performance perspective. Rust consistently shows it has better performance than c++ in code that does not hand code intrinsics. If cpu(not gpu) based performance is all you care about there is no reason to pick anything but rust. Modern c++ devs have no trouble with the borrow checker either they are already doing all the things that keep it from complaining. The reasons someone might not pick rust involve integration with existing code, the complexity of the language, and the depth of it's dependency trees. The complexity argument certainly doesn't lean you towards c++ or probably anything with an llvm back end. The openbsd approach to c is probably as simple as you can get these days short of forth or something equally obscure. Dependency trees are deceptive. We all have deeper trees than we think we do, but the rust front end itself has well over 100 crates in its tree...
All that said, I use rust for everything.