I'm of mixed feelings about this.  I can absolutely see that it can be useful, and many tools will have this kind of argument requirement.  On the other hand, as soon as you mention this pattern, I can think of a number of others that could be useful (and not implausible) that will remain unavailable.  So it's a trade-off  about how much is done in argparse configuration itself, versus how much is done in manual validation of arguments.  Right now, of course, I can write a manual check:

if (args.foo and not args.bar) or (args.bar and not args.foo):
    parser.error("Args foo and bar must occur together")

I don't care whether this checking is done with the future match/case construct versus current if/elif style.  Obviously, there are possible ways that extra arguments to .add_argument() could describe that check, if such were added.

But let us think of other possible patterns.  What if we need "at least 2 of these 5 arguments"? I can conceive of ways to add more parameters to .add_arguments() to cover that, but it's not obvious that would be worthwhile.  There will probably remain situations where a manual post-validation will be needed.  I'm not sure that "mutually inclusive" shouldn't remain as such.

Now a personal confession.  I'm far too lax about argument requirements in what I write; my audience is either myself or fellow developers.  Pretty much I just rely on "you should use this tool correctly.  So if hypothetically, the real usage of my tool is:

mytool ((-foo & -bar) | (-baz & -bam))