Imposter just made the exact same point I was about to make. Pipewire doesn't seem to have a well-defined purpose.
On the one hand, it seems to project itself as a low-latency, high-throughput audio system (like ALSA or JACK). It seems to think so because it replaces jack to the point that you can't have both running. So someone apparently thinks that Pipewire is going to be so comparable to jack that musicians (ie, jack's target users) aren't going to use "real" jack anymore. In order to do that, you have to lazer-focus on audio features only, with the minimum amount of code (ie, no extra, unnecessary features that aren't needed specifically by audio apps). I'm quite familiar with the jack code base, and it's all about audio.
On the other hand, Pipewire also seems to think it's not an audio-only system, as evidenced by its video considerations, and device management. In fact, it doesn't even seem to be concerned with latency/performance and high quality audio as evidenced by its bit and rate interpolation on-the-fly, and allowing apps to have different buffering, (neither of which jack does because that really tanks speed and audio quality). So someone apparently thinks that Pipewire is a generic audio system comparable to PulseAudio, to be used by non-music productivity apps for generic sound I/O.
This bipolar focus strongly suggests to me that the folks who are "waiting for Pipewire to mature, and then all its current limitations will be fixed" are going to be waiting a long time (like forever). There's no way Pipewire is going to ever be two entirely different audio systems. If that were easy to accomplish, Microsoft and Steinberg would have long ago replaced their two audio APIs with one API that did what both ASIO does for music apps, and what the Wave API (including PlaySound) does for generic apps. That never happened because it would be impossible to come up with something that worked as well for both use cases, as the two separate APIs do.
Frankly, I suspect that what you're currently seeing from Pipewire in terms of performance, compatibility, reliability, and most other considerations today, will remain much the same throughout the lifetime of the code. I don't expect it to miraculously overcome the discrepancies between a very focused, performance-prioritized API, and a very generic, feature-prioritized API. No amount of "maturity" is going to overcome the implications of software design.
I predict that Pipewire will be another PulseAudio, used by lots of generic linux apps instead of PulseAudio (but as is so typical, the latter's legacy will survive just enough to be a PITA to people configuring linux audio... to which Pipewire will be a further shot in the foot). Musicians will get tired of struggling to get Pipewire to perform as well as jack, and dealing with various piddling little incompatibilites. They'll go back to trying to get real Jack and Pipewire to peacefully co-exist (and work) on the same system so that audio works both for apps like Ardour, as well as their browser. And it will be just as much of a hassle as getting PulseAudio to peacefully coexist with Jack, except you'll have that app which still uses PulseAudio, so now you'll have to get PulseAudio to peacefully co-exist with both Pipewire and Jack. And if you're trying to run everything through Jack (so you don't need to "patch your audio" everytime you switch apps), it will be a nightmare figuring out what needs to be disabled in Pipewire and PulseAudio, and what needs to be "bridged" in jack, so that these 3 wanna-be-head-chefs don't prevent each other from even getting into the kitchen.