IMO it's no odder than disallowing dicts as dict keys: it's a hack that allows a much faster implementation.
Except that sets are an extremely well-developed concept apart from Python, and you can only go a little way using set-based approaches before sets of sets are a screamingly natural occurrence. In that respect, sets that can't contain sets are akin to limiting integer arithmetic to 32 bits (also a hack that allows a much faster implementation, but screaming speed just isn't Python's forte -- this line of argument belongs more in Fortran-Dev).
That is, like sets of sets in Icon too, this is a notion of inclusion by object identity (although Icon does that on purpose, while the BTree-based set mostly inherits it from that BTrees don't implement any comparison slots). That's very easy to implement. It's braindead if you think of sets as collections of values, but that's what taking pain too seriously leads to.
I don't think it is acceptable to have sets-of-sets but test for membership (in that case) by object identity.
If you really think object identity is all that's needed, I suggest we stick to disallowing sets of sets; algorithms needing sets-of-set-object-identities can use id() on the inner sets.
I called the object identity approach "braindead" for those who think of sets as collections of values, and I previously identified myself as one of those suffering the collection-of-values delusion. You can do the modus ponens bit from there <wink>.