The TL;DR of it is that people tend to use MIT OR APACHE-2.0 because the compiler and std are licensed under MIT OR APACHE-2.0. It's a lot easier to go with the community standard than to try to understand subtleties of licensing to choose an appropriate one.
MIT and APACHE-2.0 are also "well-understood" OSS licenses, whereas MPL is a much less widespread license, so developers are less likely to know what they can do with an MPL library than one under MIT.
So why did Rust go with MIT OR APACHE-2.0 rather than MPL-2.0? If I properly recall seeing one the people who were around early (graydon, even?) saying it, it's because MPL-2.0 didn't exist when Rust first started development, and was licensed under MIT OR APACHE-2.0, and if it had, it likely might have been licensed under the one license rather than the OR it is today.
And there's the tertiary benefit that as MIT and APACHE-2.0 are both relatively short, they're decently approachable to try to understand as a nonlawyer. MPL, while not terribly long by license standards (and, based on me scanning it while I should be asleep, so, not very well, reasonably approachable), still feels more imposing to try to digest.
Compound that with the greater "cultural understanding" of the more common MIT and APACHE-2.0, and you get a reasonable enough doubt to cause people to stick to what they (think they) know.
Now, with the full disclaimer that I Am Not A Lawyer, and nor do I actually pretend to properly understand these particular licenses,
As I understand it, MIT OR APACHE-2.0 presents mostly the same protections and rights as MPL-2.0.
I also fail to see how the patent clause is materially different. Pulling the text from APACHE-2.0:
§3 Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.
Definitions:
"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.
"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.
This is a patent grant from the Contributor(s) to the users of the software. This patent grant still exists even if the software is used under MIT. Just because you use the software under the terms of one of the OR'd licenses doesn't mean you don't also have the rights provided by the other license.
While, again, I am not a lawyer, I suspect any suit that attempts to argue that, for some given software revision that is available under MIT OR APACHE-2.0, that some user who is transitively using the software reexported only under MIT is in violation of patent law to be quite ill-advised and likely to be quickly lost.
Nothing prevents you from using a license term that is different from that of the standard library, or even one that isn't OSI approved. Just be aware that if your library isn't clearly, unambiguously compatible with being used by a MIT OR APACHE-2.0 library, it's much less likely to be used by a big name in the Rust OSS ecosystem (with the biggest being, of course, the stdlib and compiler itself).
Mostly off topic side note:
Most OSS licensing misses the "point" of OSS as a culture, anyway. OSS as in FLOSS matters to some people (and for who it matters it matters), and developers typically want their software to be freely usable as championed by the OSI.
But OSS "culture" isn't about distribution of a product, but rather about the production of a product. A project isn't really "open source" in the common understanding of the term if $megacorp releases a code dump under $osi-license every 6 months and proceeds to develop it behind closed doors like any other proprietary software.
I expect to see OSI lose control of the OSS term (more so than they already don't really have control over it) and OSS to migrate to mean more about "developed in the open" rather than "viewable source" or "OSI licensed." It'll be gradual with the new generation of developers, but the shift I feel is already happening.