Sorry Dan, we're going to pass on this one.  The current behavior was an intentional design choice by Guido and reflects a careful balance between some difficult trade-offs.

An early and permanent mistake in Python's design is that list.__iadd__() and list.extend() both accept any input iterable.  For extend(), this proved to be useful.  In contrast, __iadd__() was a recurring bug magnet.  People would routinely type "s=['abc']; s+='def'" expecting to get ['abc', 'def'] rather than ['abc', 'd', 'e', 'f'].   Based on this experience, Guido wisely opined that math operators on other concrete collection classes should be restricted working with members of their own class.

When abstract base classes were introduced, a seemingly inconsistent decision was made.  The Set ABCs allowed the math operators to accept any input iterable and did not provide the spelled-out method names (union, intersection, difference, etc).

IIRC, there were several reasons for this.  It kept the total number of methods to a manageable size (important so as to not unduly burden implementers of concrete classes).  Also, having a same type restriction is at odds with some of the design goals and use cases for collections ABCs.  Additionally, the code for the mixin methods is simpler without the restrictions.

When dict views were implemented, they followed the Set ABCs.  This gave them fewer methods than sets but also gave them fewer restrictions.  For the most part, these design trade-offs have worked out well in practice.  The existing behavior is neither "needless" nor "arbitrary".  It was the result of careful consideration by GvR on what works best for most people, most of the time.