Can confirm. Matching decompilation in particular (where you match the compiler along with your guess at source, compile, then compare assembly, repeating if it doesn't match) is very token-intensive, but it's now very viable: https://news.ycombinator.com/item?id=46080498
Of course LLMs see a lot more source-assembly pairs than even skilled reverse engineers, so this makes sense. Any area where you can get unlimited training data is one we expect to see top-tier performance from LLMs.
I absolutely agree that Microsoft could do better, but they are making progress in removing support entirely for broken (from a security perspective) older protocols such as NTLMv1 (which uses DES as well: more here -- https://bit.ly/crackingntlmv1) and SMB1.
The financial incentives drive Microsoft to support every possible (mis)configuration, forever. It's the tireless work of a few folk at Microsoft like Ned Pyle, Steve Syfus, and Mark Morowczynski that have landed the changes so far.
There could absolutely be a "security check" tool deployed by default with Server 2025 or similar that looks for Kerberoastable user accounts (any account with a ServicePrincipalName is technically Kerberoastable, like computer accounts), AS-REP roastable accounts, weak encryption types, etc. That would probably get more traction than changing defaults out of the box for everyone, as that's another way to phrase "breaking customer environments when they upgrade".
KeySavvy is the normal workaround for this. $99 extra cost to both sides for them to handle the title verification and shipping, and to act as the dealer to make it qualify for EV credits.
We don't advance as a society unless people ask new questions. Having folk willing to spend some time answering those questions (in public, no less!) helps others. It's really, really damn hard to predict how advancements in one area can help another.
All that said, thanks for your interesting new question, and thanks for spending time on it :D