Earlier quoted context omitted.
On Linux, often times you will be using SDL3 regardless, as sdl2-compat and sdl12-compat are the default implementations of SDL2 and 1.2 on some distros. This has a lot of benefits, from more apps working natively on Wayland (which gives lower latency than XWayland) to better controller support. Not sure what this meant for osu but I wouldn't be surprised if it made the actual switch less impactful for some users. I…
Don't most games ship their own build of SDL?
For Windows and macOS, it is just a flat "yes", since obviously in that case SDL isn't a system library.
If you're installing a game on Linux via Steam or Flatpak it isn't going to use system SDL in any case. Minecraft would probably ship a binary for use with JNI as is customary.
However, when running games outside of Steam or Flatpak, especially open source games but certainly even outside of open source, it is not uncommon to use packages that adapt the game for your OS, like AUR packages or Nixpkgs derivations. And in that case, you'll likely get system SDL. This would be the tendency for emulators, games that are open source like ioquake, and so on.
Even in a case where SDL2 is statically linked, it is still possible to attempt to load SDL3 by pointing SDL_DYNAMIC_API to a copy of sdl2-compat.
I don't know what Steam does here, but I think it doesn't matter. A large amount of the commercial games you wind up playing under Linux are running under Proton anyway at which point the SDL version makes little difference if it is used at all. So I think it is still likely to see a lot of SDL stuff silently upgraded to SDL3 on Linux, though yes there are caveats to that.
Edit: Also, I wanted to make an additional note: the Ubuntu 24.04 note is still relevant even in the face of most games shipping their own SDL3. The reason for this is simple, I think to this day a lot of people (myself included) use Ubuntu 24.04 as a sort of general Linux build platform for building binaries that work pretty much anywhere. What you wind up having to do if you want SDL3 to work there is to build it, either via your build system (not so bad to do, either via vcpkg or via CMake subprojects) or just outside the program's build process altogether. It's not asking too much, especially since SDL3 compiles very quickly relative to a lot of other software, but still, it adds some complexity that you don't get when just building with and linking to SDL2 where you can install the dev files and binaries directly with apt-get.
Edit 2: It seems Steam is using both SDL_DYNAMIC_API and sdl2-compat as of Steam Linux Runtime 4, according to Google's AI overview. Take it with a grain of salt, as I didn't feel it warranted a deep investigation, but this suggests to me you're quite likely to encounter SDL3 within Steam (for native Linux games) regardless of what the game ships.