Those are cases where DKIM is working against the user! I get that we can come up with cases where we're glad some hapless user is undone by DKIM, but when we're discussing messaging security, we generally take the side of the hapless user, not the courts and tort lawyers!

An email exchange has two users: one is the sender, the other the receiver. As the receiver, having proof that I received an email from you is potentially a feature, not a problem.

More generally, authenticated communication has a long history of being considered a useful thing for society. Physical mail includes delivery confirmations where the receiver must sign for the receipt, proving to anyone that they did receive the letter. People would often add hard-to-forge personal seals to letters in even older days, that could prove to anyone that they were the ones who sent that document. And even common letters were usually signed rather, even when typewritten, again making it hard to later repudiate.

While I absolutely see the value in making it possible to securely send repudiatable email in some specific circumstances, I think having non-repudiatable email as the default is a net benefit to society, and has been the de facto standard for at least a few hundred years before email ever came along.

This is the classic argument in favor of verifiable DKIM signatures: because it benefits the consumers of hacked mail spools. Consider that as a security engineering decision, enabling that use case is a bad thing.

It would then make sense to encrypt the email content.

Repudiation of clear text messages looks like the easier implementation.

That creates other problems. Content analysis is a large part of anti-spam. Which is a much more important problem than (non-)repudiation and all that.