From what I can tell all this new stuff isn't coming anytime soon. Maybe LinAlg, but the rest is post-crossgen. So realistically well into 2030s.

I'm not sure what you mean. All of the SM6.10 features are things that all relevant hardware already supports and they just weren't exposed directly in the API. LinAlg of course doesn't make sense to support on hardware that has no tensor ALUs and the new ray tracing intrinsics don't make sense on hardware that doesn't do ray tracing, but Turing is 8 years old at this point. Those features are also going to be optional based on the respective feature flags separate to the shader model, so the rest of SM6.10 could ship on some very old architectures. Microsoft has been very careful about what is optional or required in shader models because of the way they are versioned. RDNA2 won't get SM6.10 because AMD decided to not ship new features in the driver, not because there's some hardware reason. Group Wave Index/Count is a convenience feature and closes a gap in the specs that previously had to be filled by ugly workarounds in code, it does not require new hardware. Variable Group Shared Memory is just exposing actual hardware limits instead of a hardcoded limit, does not require new hardware. Batched Asynchronous Command List APIs is not even part of a shader model at all since it requires no new shader (pseudo-)instructions, does not require new hardware. It's all just drivers.

Does that sound accurate and what is the cutoff SM 6.x that game devs are using for actual shipped games rn?

I think this is the wrong question. As I said, Microsoft is careful about only hard requiring things in shader models that are very widely supported, since you can only claim support of a higher number if you support all of the required features for all the previous ones too and they don't want to gatekeep something as simple as GetGroupWaveIndex behind a huge feature like Work Graphs. Typically hard requirements are only ubiquitous things that they also want to make sure don't somehow regress when a vendor does a more "clean slate" new design, to give developers some peace and security.

SM6.6 is one of the "big" ones with proper bindless resource support required and is supported on any hardware less then 10 years old, so that's a good minimum target even for people targeting a wider audience. As of right now, it seems like SM6.8 is supported on anything since RDNA, Maxwell v1 (from 2014!) and Xe-HPG/LPG (Alchemist/Meteor Lake, not Raptor Lake or earlier which is Xe-LP, thanks Intel for making things maximally confusing and screwing over your customers). SM6.9 only just released 2 months ago and we don't have new reports for all hardware yet, but based on the required features it could be supported all the way back to Turing 16 and possibly even Vega/GCN5 if they wanted to, but of course AMD will restrict it to RDNA3+ because they wanted to hard fork their codebase and not spend effort on even slightly older archs. Still, just supporting SM6.8 or 6.9 doesn't give you anything super big, it doesn't mean you get Work Graphs on RDNA1. There's certainly some improvements/convenience from the smaller required features, but it's not like you'd drop entire generations of hardware for that and whether you'll implement both new and old codepaths is dependent on how much work it is, what the benefit is and how badly it affects code maintainability.

If you really want to dive into the zoo there's this convenient page showing you all the optional D3D12 features and on which architectures they are currently supported (based on user-submitted reports, so it will always lag behind a bit, e.g. the last Turing report is from February). Note this won't show you the required features that don't have their own separate feature flag and are instead subsumed into larger version numbers/tiers, you'd have to look at the respective specs for that (e.g. the shader model specs, ray tracing spec, etc.).

Talking about some big name features, the AAA industry is slowly starting to require ray tracing and/or mesh shaders for some games, so that cuts things down by quite a lot and is easier to justify since they're such big features, potentially changing the entire approach to rendering. I doubt anyone is trying to use Work Graphs outside of experiments at the moment. It's too new and the performance isn't there yet afaik. Sampler Feedback is for some reason a weird pet obsession on reddit because people think it will magically reduce VRAM requirements, but the only things I've heard about it from actual developers is that various parts just do not work at all, every vendor has different bugs and it's harder to use than the existing solutions which everyone already has, so regardless of support nobody seems to actually be using it. Don't believe every tech demo you see does a fair comparison and is actually applicable to the real world. Variable Rate Shading has been widely used for quite a while, especially because it's typically just a relatively easy performance amplifier, so your fallback when not supported is just rendering normally and a bit slower. 16-bit shader ops are quite useful (though not as trivial to optimize for as one might think at first) and afaik used pretty widely, potentially requires fallback 32-bit implementations, mainly to support Pascal since that was such a successful generation and it still has decent market share.

There's obviously a ton of other optional features, it's not like I can talk about them all nor do I have insider knowledge on who is using what. Some of it is API convenience or small optimizations (e.g. tight alignment, create at byte offset, increased 1D dispatch size, etc.). There's Intel regressing on resource heap tier with Xe-HPG, which was really weird but not the biggest deal, the lack of 64-bit atomics on typed resources and group shared hurt more (they shipped a custom extension that provided some limited form of support because otherwise UE5 Nanite wouldn't run on Intel, which would be very bad PR).

Sorry, at this point I'm just rambling randomly and I don't really know what my point was or even what you wanted to know. 😅
There's also this article from a AAA developer with some comments on various D3D12 features introduced since its release.

What are your thoughts on the No Graphics API proposal by Sebastian Aaltonen.

I've been meaning to read it but haven't yet. I'm also maybe not the right person to ask, my experience is too limited. As a general comment, it's always easy to sit on the sidelines and imagine something better when you don't have to talk to a dozen hardware vendors to get them to align or have reasonable backwards compatibility (and forward compatibility for new hardware designs that you haven't even thought of yet). It would definitely be possible to clean up the current API designs, but it's an incredible amount of work, mostly done by very few people because it's not a revenue generator and a hard cut is always very disruptive.