SDL, for example, which will use js devices depending on the circumstance.

Your own link points out that even SDL 1 — very old now — doesn’t use the js interface unless forced to do so.

In other words, people with stick drift can calibrate it away using the js API, and have it applied to SDL 1 games by setting an environment variable.

In any case, I don't know why you're campaigning so hard against my suggestion to start with the js API. It's easier than calibrating evdev, it actually affects the generated stick values (unlike evdev), and there's certainly no harm in starting with it. A more interesting pursuit would be determining whether any popular input libraries apply evdev's deadzone/flatness value before passing stick readings to a game.

I’m running Debian trixie.

Debian Trixie does create js devices.

IIRC in the past, for a while when the evdev interface showed up, a problem was that games that could talk to both interfaces would sometimes get double input, because a number would aggregate all input from all joysticks, and so if one had both the js and evdev interfaces visible, they’d see it as two joysticks both; a fix was to not expose them via the js API, rather than leaving them exposed via both. I don’t know how that’s evolved over time, but it may have been a factor encouraging not exposing them by default. I’ve certainly seen the “double input” behavior myself, maybe ten, fifteen years back.

I'm looking at a Trixie system right now, and /dev/input/js0 appears just as expected. Is it possible that you modified your Debian installation way back then, to disable your js devices? Maybe you (or some package you installed) applied a udev rule to block them?