AFAIK ALSA-only distros tend to have SW mixing configured by default and PulseAudio-based distros have ALSA intercepting enabled by default. So in practice an application that needs some basic audio playback can just use ALSA and it'll work everywhere.
"In practice" doesn't mean what you think it means.
The behavior I described was with a Pinebook Pro which only came out about a year ago. That was running whatever version of Debian they shipped-- either stretch or buster, can't remember now. And there was no fancy or custom audio setup-- it was just an XFCE desktop environment with Pulse running however it's configured to run by default.
Also, as a maintainer of realtime audio FOSS software I can tell you users have reported these exact problems on other Linux distros. Over at least the last year and a half.
It appears that in Debian testing the configuration of Pulse "just works" as you describe. I would rankly speculate that Ubuntu 20.04 probably has a similar default setup. But to turn that rank speculation into "in practice" we'd need to actually test and see, and it sounds like neither of us have done that yet.
BTW what i describe is how Debian was for years when i used it by default, not just testing. It is possible that the version of Debian Pinebook Pro shipped was altered. Or something else wasn't configured as i had it, who knows.
Are you trying to hook Bitwig up to other realtime software with jackd? Because if not-- e.g., you're just trying to output sound from Bitwig with the lowest latency possible-- there is absolutely no point in running jack. Go straight to ALSA.
Note: I'm not familiar with Bitwig and am assuming it isn't a weirdo that somehow prevents you from setting ALSA as the backend on Linux.
The downside to "straight-to-ALSA" is that a realtime prog will gain exclusive control over the audio subsystem. So someone who wants to watch a youtube video demo on realtime prog Z and run realtime prog Z to monkey along will end up with a frozen video as it blocks (or perhaps Pulse blocks) waiting for prog Z to release the audio to it. (Or if the video started first, prog Z will (hopefully) error out trying to gain an exclusive connection to ALSA that it cannot get.)
Pulse is valuable because its default behavior solves this use case. Jack can be set up to do this, too-- I have used Qjackctl or whatever to automate this use case when setting things up. But at least last time I used Jack I had to "opt in" to this obvious setting of "pipe the running stuff to the speakers, please." E.g., I had to do business with my brain and some global mutable state. Not sure if that's changed.