Easier said than done without robust user management features not present in Team Edition. With the limit presumably based on activated users rather than monthly active users, this means once a user is deactivated they cannot self-serve return without admin intervention creating a host of problems. Sure it may drive license sales but it may just drive people away.
Maybe but with the implementation timeline discussed here (limit starting in March release) it seems like the limit will be in place before some admins are even seeing the warning let alone get ahold of Mattermost, Inc. to discuss options. It is not uncommon for admins to skip releases.
Environmental Law is outside my area of knowledge or expertise 
@it33_mattermost this is an interesting explanation of Team Edition that I have not seen (or simply missed) before. Pricing | Mattermost hints at it, though as previously discussed “Unlimited Teams” confuses the point. Mattermost editions and plans — Mattermost documentation doesn’t really seem to communicate the point that it’s designed for a single team until you get to plans which at skim I would have assumed would only apply to Enterprise Edition.
I agree the name Team Edition given the explanation makes sense but I’ve always just seen it as Mattermost open source and Mattermost paid edition - I’ve only used it via GitLab Omnibus package which doesn’t really seem to call out the intended use case or edition - GitLab Mattermost | GitLab. Interestingly, upon looking now I see the download for Team Edition is even buried away quite a bit and not mentioned much. Also unclear how or if it can be used on Kubernetes.
If Team Edition is made for a single team it seems it may have made sense to restrict the multiple-Teams capability to Enterprise Edition when introduced. I would highly recommend not making that change now. This thought exercise has helped clarify what bothers me most about the 10,000 user limit: it’s moving/restricting a capability currently in the open source version to the enterprise version. Removing/restricting capabilities in open source tier in favor of paid tier is something that a number of companies backing open source products have vowed not to do, like GitLab (stewardship promises):
When a feature is open source we won’t move that feature to a paid tier.
I had hoped Mattermost, Inc. operated under a similar promise given how similarly the two companies operate.
Now if we’re talking implementing an overridable safety limit that could be a bit different conversation (same story if it were just an annoying safety warning to admins). GitLab promises “the open source codebase will not contain any artificial limits” but they do include sane default limits which can be overrode (though not always easily) if admin believes/sets up infrastructure to handle it. If Mattermost, Inc. were to allow the safety limit to be changed or override (without re-compiling the code base), I don’t think this is such a controversial change (whether it’s breaking or not is still up for debate). Without such override I see the change as ultimately commercially motivated, and not in line with the promises other companies have made in regards to the open source software they maintain.