Another possibility is government applications like taxation, where your physical identity is 1:1 mapped with your system identity and rigidly enforced.
Or online multiplayer games where you are placed in a specific tenant, usually geographically bounded, and can't join other ones. Sometimes you can migrate or pick which one to join, but you can't play across multiple simultaneously. This would depend on whether you consider the serving layer of these games to be SaaS I suppose. World of Warcraft famously forced an account to be Horde or Alliance in the early days, most modern mobile games don't tell you that your geo bound until you try to add a friend on the other side of the planet.
Otherwise I can only think of a couple of edge cases, as I suspect you are meaning for a typical multi-tenant B2B or B2C SaaS product. The blocker here for me would be that you are limiting your product from ever doing in-product sharing and collaboration.
At Tb, If we set up a dedicated instance for a specific use case for an enterprise customer, like say low-latency log analytics, then all users tagged to that use case are directed to that instance. The user may have other tenants for other use cases, but that one is optimised for that purpose.
Likewise if we have a B2B2C use case, such as processing the metrics for personalised analytics dashboards for each of their tenants, then their pass-through users (if you think of it that way) also only belong to a single tenant that is optimised for that use case.