Sounds to me like his choice of Zig was made in haste, as was his choice of Rust. If you find yourself changing a project's primary language more than once a decade (more like 15 years, but let's say a decade), the problem isn't the language but your technical decision process, and that's what you should look into first.
Some of the world's more important software - from browsers to the JVM - mix high-level languages with a GC and low-level languages, and it works not because of a style guide (even though one may exist). As someone working on the HotSpot JVM, I can say that it's done with a lot of thinking about constructing the right primitives that make this work well. Zig doesn't lack the features to construct the mechanisms required for getting good results in that domain, and Rust doesn't have features that could save you the thinking about such mechanisms.
I should add that in the 30 years I've been a professional software developer, I've worked on and advised many projects. They all ran into serious challenges at one point or another. Not of those projects that was held in high technical regard changed their language (except for things like JS -> TS or when the project planned to change languages, starting with one suitable for prototyping and expecting to switch if and when their workload grew).
All the ones that opted to switch language after less than a decade were those with serious shortcomings in their technical decision process, and those problems, unsurprisingly, persisted after the language change. After all, the very decision to switch so soon is an admittance that they'd made a very serious misjudgment, but these projects never properly debrief why they'd made such a big mistake and how they can avoid making one again.
likely you never were on a project that had tens of millions of users, you hit different classes of problems and you have to scale to new runtime or language often
(BTW, when I wrote "Not one of those projects ... changed their language", I meant after less than a decade, as a continuation to the previous comment)
First, technically respected products like the ones you describe either 1. plan or expect to switch in advance (e.g. they start with, say, Python/Ruby, expect that if they grow they'll switch to, say, Java) or 2. they improve their chosen language runtime (e.g. Facebook with PHP/Hack or Shopify with Ruby). Projects that switch a language without expecting to always show a pattern of bad decisions (clearly, if they thought their chosen language will carry them through growth and then they're convinced that it won't, that means that they don't know to judge languages' merits).
Second, this is clearly not the situation here, is it? There is absolutely no new information that Bun learnt in the past year that they didn't have five years ago, and certainly this has nothing to do with growing workloads on some service. They say they believe the language they have chosen lacks the features needed for the very core of the domain, which is dealing with JS objects. As someone working on the HotSpot JVM, I can tell you this is not true, but fine - that's what they believe. What could have taken them five years to come to that conclusion? Again, this happens to be a domain close to my own, only much simpler, and I seriously doubt they made some novel discoveries in the past year. And if it's taken them five years to acknowledge what they now think are fundamental limitations with the language they had chosen, how can they be so confident they've made a right choice now after a few weeks? It looks like they chose Zig on a whim and then chose Rust on a whim, and neither of these choices is the source of their problems and neither is the solution to them.
Some of the world's more important software - from browsers to the JVM - mix high-level languages with a GC and low-level languages, and it works not because of a style guide (even though one may exist). As someone working on the HotSpot JVM, I can say that it's done with a lot of thinking about constructing the right primitives that make this work well. Zig doesn't lack the features to construct the mechanisms required for getting good results in that domain, and Rust doesn't have features that could save you the thinking about such mechanisms.