We banned all these forks at work.
The dev onboarding overhead is not worth the benefits.
Having all 1700 repos using the same build tooling is more important than slight increases in build performance.
When you have a lot of projects to support, it's rare for the benefits to outweight the costs
For what it's worth, I'll say that I can understand such top down governance: you'd have an easier time around moving across projects that you work on within the org, there'd be less risk of a low bus factor, BOM and documentation/onboarding might become easier.
Same as how there are Java or .NET shops out there, that might also focus on a particular runtime (e.g. JDK vendor) or tooling (an IDE, or a particular CI solution, even if it's Jenkins).
On the other hand, if the whole org would use MySQL but you'd have a use case for which PostgreSQL might be a better fit, or vice versa, it'd kind of suck to be in that particular situation.
It's probably the same story for Node/Deno/Bun, React/Vue/Angular or anything else out there.
No reason why that mandated option couldn't eventually be Bun, though, for better or worse.
This can become a big time sink on bigger teams. That time could be saved by just not allowing it until a full team initiative is agreed on.
Bun is really nicely compatible with node.
Speed of course is excellent, but the main reason I use Bun and recommend it:
You replace node, npm, tsx, jest, nodemon and esbuild with one single integrated tool that's faster than all of the others.