That "pile of explicitness" replaces a pile of implicitness wrapped up in case law and statutes that are relevant to any case that arises but you don't know about. Because what you read in a license is not what matters--how do you know you understand them as they will be interpreted by a court of law? What do you not know that you do not know?
This sounds like FUD. When has a simple license like BSD been interpreted to not grant rights to the patents implemented in the technology being licensed? The language there is really clear.
I don't know. Turn it around: when has it been interpreted to grant rights to patents implemented? Is there case law that establishes estoppel for such a thing? Has it been tested? Are your lawyers good enough?
These are questions that you should be asking because the name of the game is minimizing risk.
Still FUD. When someone distributes something under BSD and spends non-negligible resources promoting that software, they lose the ability to sue people for using it, because the language of the license says "you may use this". The risk is 0 and I would be surprised if this has even been argued in court because it's so trivially clear.
Don't be "surprised if", don't make blurfy engineer claims--cite your sources or withdraw your claims of safety that do nothing but encourage other people to undertake risk on behalf of your ideology.
The sooner the software developers of the world realize that there are reasons that we hire lawyers for legal tasks just like we hire programmers for programming tasks, the better. The profound arrogance you are choosing to exhibit regarding complex professions you don't fully understand is one of the absolute worst things in tech.
If I can't trust the justice system to interpret a simple contract plainly, then I don't have a chance of actually understanding the legal implications of a more complex contract.
The justice system is like a computer. It has no common sense; it has no "Do What I Mean" button. You have to write things out in full explicitness, for it to do anything predictable/sensible at all.
And just like with explicitness in programming, explicitness in a contract doesn't translate to "more things that could go wrong"; it's instead fewer degrees of freedom. More things pinned down; fewer left to interpretation.
I expect that unexpected results may come from unexpected scenarios, but not in relation to basic questions that appear to already be addressed in the contract, like "can I use this software?" If I can't trust that a statement means what it says, no amount of elaboration can clarify the contract.
I get what you're saying, but calling it "like a computer" is a little misleading and feeds that weird habit amongst technical people of assuming that The Letter Of The Law is all that matters, when really it's the boatload of precedent, moral justification, and historical context that informs that law.
It ain't hard fact until a judge says it is, and even then it can be moved with a big enough lever. That that specificity reduces axes of freedom on which to have what you think is obvious be not obvious is why I upvoted you, because that's the super important part everybody ignores.
Right, you can't actually "rules lawyer" in real law; there is a spirit of the law that informs connotation of the text where edge-cases are concerned.
A good lawyer tries to phrase their contracts et al to expose the connotation of the relevant laws in the text, so that you don't need to read the laws, only the text. Sort of like explicitly including default parameter assignments to a function.
You seem convinced that your interpretation of a "simple" contract is the only obvious one and that any other interpretation is unecessarily convoluted. But I don't think that is the case at all. Simplicity almost always comes at the expense of clarity, which is why simple documents like the MIT license or the US constitution produce so many conflicting interpretations. Not because there are bad actors; just because it is unclear.
If you ask a lawyer what is best, they will likely recommend a professionally drafted license like the Apache License v2. Just as you may not understand every aspect of a doctor's diagnosis or prescription, it may not be feasible to understand all the relevant statutes and case law. But I think it makes more sense to defer to expertise advice than to bury one's head in the sand.
You're assuming that because a contract is simple you're more likely to understand it correctly. That is horribly misguided.
In all likelihood you don't fully understand contracts regardless of length because you're unaware of the entire legal environment they exist in. The reason contracts often have weird stilted phrases is that they have specific meanings established over decades if not centuries of legal battles over those semantics.
A good example for doing this right are the Creative Commons licenses: they come with a summary in plain English for humans and a full license text for the legal system.
(This is why companies have legal teams.)