I think writing their own physics engine might be wrong way to go here. I understand that Bullet leaves a lot to be desired, but my instinct is that the complexity from their own engine will leave a lot of edge case bugs that need to be ironed out over time, and that games using their own physics engine will suffer from a lot more quirks in the meantime.
A few years ago, as someone who has worked on physics engines for robotics simulations, I would have agreed with you. But now a lot of people are doing greenfield physics engines for games and having it work out pretty well. There's a ton of established academic and conference literature in the area now and it's not nearly as scary as it used to be.
For example, Horizon: Forbidden West uses a custom physics engine that started out as one of the core dev's fun side projects: https://github.com/jrouwe/JoltPhysics
Physics engines (at least game quality physics engines) are starting to drift in to "solved problem" territory and there's enough literature now that you can get something reasonable going yourself after doing some weekend reading.
Edit to add: Godot has had its own engine available for a long time, so it's not a totally new effort. It's a heavy refactor and a large improvement but the bones for this were laid years ago so some of that technical debt you're describing has already been paid down.
I've briefly looked into physics engines and they seem to require a lot of trade-offs. If a rock meets a hard place, what should happen? Gamers have seen the hilarity that can ensue. Designing your own engine allows you to make those trade-offs with the end goal in mind. You can do things like set global force or speed limits, because you know your game's design and the appropriate limits.
Lots of simulators for robotics use ODE or Bullet, actually, and they're quite good for lots of things that you might want to simulate. But there are some people who would argue that they aren't the best for it, especially for simulating legged locomotion, because of the way physical constraints such as joint limits are enforced (via Lagrange multipliers). A popular alternative formulation is Featherstone's Method[1], which is becoming more widely available and goes by other names sometimes; for example, Rust's `rapier` physics engine refers to this type of dynamics model as "reduced coordinates" (they don't yet support it, but it's on their roadmap). Featherstone's method is becoming more popular but it's still not widely used in a lot of physics engines because most physics engines are targeting games and Featherstone's doesn't always have the best performance characteristics, instead favoring physical fidelity. Bullet can run using Featherstone's Method, by the way. One of the few FOSS engines I know of that supports it out of the box.
Additionally, there are people in robotics who like to say that simulators are like lightsabers, you haven't become a true Jedi until you've built your own, so there's a lot of home grown physics simulators in robotics.
One of the benefits of 4.0 is also the modularity of it with GDExtension. The major parts of the engine (including the physics) can be swapped with replacements without the need to recompile the entire engine. I'd usually say that is a long shot for community run projects, but even Bevy engine has community made extensions for separate physics engines.
Forgetting about extensions, though, I see your point and almost agree, but Godot has shown that they will put in the work to improve their project, even if that means removing features like they did with visual scripting. Their physics engine will definitely be rough at first, but based on their past work, I believe they are willing and able to maintain it.
I reckon they're thinking long term here though, if they don't change it now then likely the only time they could change it is when a theoretical Godot 5.0 comes out in who knows how many years.
It sounds like it's got bugs that need fixing either way, so at least for their own engine they're not reliant on anyone else to get those fixes out (or have to use hacky workarounds as would most likely be the actual fix).
From everything I heard the existing physics engine was already buggy/hard to work with, which is harder to fix because either they had to fork it and then maintain compat themselves or ensure all their changes got accepted upstream. At some point it can easily make sense to just go your own way, and I can't fault them for deciding to do so.
