Well, I don't want to give users additional information, just rectify the manipulated information. And yes, while there may be edge cases where these bad practices do come in handy, but the vast majority of mails (at least from what I can tell from my lists) is either spammers or unnecessary abuse of features. I can't tell if it's because Microsoft sets bad defaults for Outlook or admins hired are incompetent and the competent ones either retire or quit, but there's just too much going on in mails that's just nonsense. E.g. encoding all text - including stuff like the subject - with base64 is just ridiculous, when what was sent is only plain text that uses a small subset of UTF-8 characters. And that's just a very common bad practice and far from the only one.
And sure, competent spammers may be able to evade much more, I've seen several emails that must have had manipulated sender data, but that could only be concluded from context, not from analyzing the headers. But thankfully most spammers are far from competent, so spam filters can easily detect far over 50 % of the spam. It's only the slightly more competent spammers that use tactics abused by many non-spammers that give me a headache. I could easily crank up the spam points for various indications, so there would be pretty much no spam left in the false negative category. But sadly, I know from experience that this will lead to a much larger amount of false positives. For the most common senders that won't be sending spammers, I already created whitelisting rules, but that's about it. And until someone can create an ML model that's not gobbling up resources for training and that doesn't need thousands of emails to train with, there's only so much you can do.
While DKIM and DMARC are great, they are useless when the vast majority of senders don't have any DKIM signatures. For ARC it's not as uncommon to be present, but the situation isn't that much better.