There are several issues:
- License proliferation - The more licenses we have floating around, the more work everyone has to do to understand them. Case law for one license will not necessarily apply to a differently-worded license, even if they're both intended to achieve the same effect. And if everyone starts writing their own licenses, this becomes significantly worse. To get an idea of how bad the situation is already, take a gander at the Free Software Foundation's annotated list of licenses. Note the large number of licenses, and how little the FSF has to say about some of them. We do not want to make this list any longer - there are more than enough licenses to go around already.
- Legal uncertainty - If a license is vaguely worded, it may not behave as we would like in a court of law. When you write a vague computer program, the compiler will (normally) refuse to compile it; the grammar of the programming language disallows ambiguity at the syntactic level. The program may not mean what you think it means, but it does mean something.* This is not the case when you write legal code. If it's vague, the court will have to guess, and they may guess wrong.
- Contra proferentem - Ambiguity in a contract is normally interpreted in favor of the non-drafting party (with the rationale that it's the drafting party's fault for creating the ambiguity in the first place). It's not immediately obvious to me that this necessarily applies to an open source license, but if it does, it would greatly exacerbate the previous point.
- You might accidentally make a non-free license - One crayon license actually in use is basically MIT/X11 +"The Software shall be used for Good, not Evil."This is considered a non-free license (don't take our word for it, the FSF agrees), and resulted in at least one bug report asking for downstream software to be removed from Debian. This caused actual person-hours to be diverted from software development to deal with silly licensing issues that never should have arisen in the first place.
* I am ignoring the issue of undefined behavior in C and C++ because they aren't really relevant to this analogy, but if you like, you can think of vagueness in a contract as like undefined behavior, but perhaps less evil.