Bun is an all-in-one toolkit for JavaScript and TypeScript apps. It has a runtime that gets most of the attention. The main design goals are speed, TypeScript & JSX support, ESM & CommonJS compatibility, Web-standard APIs and NodeJS compatibility.
So should it replace NodeJS?
The short answer is no, but a longer answer means reframing the quest.
No because it is still immature and you are more likely to come across bizarre bugs or weird crashes during normal development. Bun has a focus on speed but it still might be less performant than NodeJS in real life applications. All in all there are lot's of risk in going for a runtime that is still under development.
A longer answer means reframing the question. At Bun's core there is the runtime, but that is not everything Bun is. Bun is an all-in-one toolkit for JS and TS apps. You can use it for so much more than just a NodeJS runtime replacement
Package manager
The Bun CLI contains a Node.js-compatible package manager designed to be faster that alternatives. You mileage may vary, but testing it out as just a faster package manager is not a huge risk but can yield significant DX and CI/CD improvements.
Bundler
Bun has a built in bundler that's API is inspired heavily by esbuild. It might have better performance for you use case and if you are already familiar with esbuild, the API feels very intuitive. The bundler supports macros and can be used to build executables making it a very interesting option for specific use cases.
Test runner
Bun ships with a fast, built-in, Jest-compatible test runner. The tests run in the Bun runtime, making it potentially a lot faster. If you are using the NodeJS runtime for production, you might still want to run specific tests using Jest and NodeJS.
Package runner
You can use bunx as a replacement for npx. Bunx respects the executable files shebangs, so the executables can still be run using NodeJS. This behaviour can be overridden using the --bun flag.
Serverless and scripts
You might not want to risk using the Bun runtime in a large monolithic application, where switching between runtimes is not feasible. In smaller programs, such as serverless functions or small scripts, it might be trivial to switch from Bun to NodeJS. So even if you do come across issues you should be fine and you could even A/B test both to see which performs better.
Conclusion
I personally love the DX using Bun runtime with it's simple API in setting up HTTP and WebSocket servers or simple scripts. In most cases, I prefer starting with it instead of NodeJS. Even having come across some bizarre issues I think sticking with Bun is the better option. I can't recommend it though, since if you come across a bizarre issues but lack the capabilities to work around them, then your only option is to migrate to NodeJS.
In the long run, Bun will become mature and stable. If it can keep true to it's design goals, it should prove to be the better options for most teams. Even if you can't go all in on Bun, it is worth checking it out and use it for what you can.