Realistically, that list of components are mostly things that have not been used in modern computing devices for over a decade. Nothing prevents someone from providing a module from out of the kernel tree to ship these drivers or delivering some of these capabilities in user space, and if they are unused and unmaintained I would rather they're not shipped in the kernel.
Be real with yourself, do you know anyone using ISA or PCI in 2026? Everything is built on PCI-E except in specific industrial settings or on ancient hardware that's only relevant for retrocomputing. Is anyone using the ATM network protocol anymore? MPLS and MetroE mostly replaced ATM, and now MPLS is being largely supplanted by SDWAN technologies and normal Internet connections. I have been doing networking nearly my entire career in some capacity, the last time I touched X.25 or Frame Relay was in the early 2000s, the last time I touched ATM was in the mid early 2000s... the last time I touched ISDN was in the mid 2010s, and that was an IDSL setup, which is itself a dead technology. The last laptop I owned that had a PCMCIA card slot was manufactured in 2008.
I don't want to see these capabilities completely disappear, but there's no reason they should ship in the mainline kernel in 2026. They should be separated kernel modules in their own tree.
I actually use a capture card on PCI but I'm well aware I'm unusual.
> They should be separated kernel modules in their own tree.
The main issue with this is that by being on a separate tree they do not benefit from the API breakage updates in the kernel. After all the main benefit that kernel devs mentioned over the years for keeping drivers in the kernel instead of separate trees is that the code gets updated whenever internal APIs change.