Firstly, it's non-standard. As others have said, it's the author's right to make it non-standard, but I don't recommend people try that unless there's a really good reason to do so. If it's non-standard, a lot of companies simply won't use it. There's no box to check, so you can't have it. Good tracking software will of course allow for exceptions and deltas to the standard contracts, but it still creates delays and management overheads as if it's allowed at all, it will require someone's manual sign-off.
This gets worse when you consider the whole chain of software use. One library inside another library that's used by a subcontractor who added it to a build script that's used by the main contractor to distribute to developers. The whole thing needs to be linked through, which is hard enough with standard licenses.
Now startups don't need to worry about sign-off from some department, but they still need to stop and inspect the nature of the licenses they're using, and a non-standard license causes extra time and energy lost.
The second problem is ambiguity. A non-standard contract can still be precisely written, so developers know what they're getting into. In this case, though, it's not. It hinges around the definition of "evil", which is naturally ambiguous.
Comedy goes a long way, but is not always appropriate. This is a good article on the subject: http://www.natpryce.com/articles/000225.html
"It may be less amusing to the programmer writing the code but, more importantly, it is less infuriating for the programmer maintaining the code." Think the same applies to licenses.
A license is like a piece of code that binds to a system of laws at runtime. Effective license terms, like effective code, work within the problem domain and avoid ambiguity where it is likely to cause problems. His license compiles, but can throw runtime exceptions depending on context.