Bob explains the

reasons behind some of the restrictions of the EJB specification

While it is certainly healthy to understand the rationale behind these kinds of
decisions, Bob omits a very critical piece of information when he advises that
these rules can be bent when you know what you are doing:  these
restrictions are also used by the container.

For example, the fact that EJB’s are not allowed to create threads makes it
possible for the container to attach important information to ThreadLocal (such
as clustering, transaction, security, etc…).  After reading Bob’s
article, you might decide that since your application will only ever run in a
single JVM, you can safely violate the rule and create threads in your EJB. 
But by doing that, you are going to break the container in disastrous ways.

Bob gives the example of an over-zealous architect who decided to follow the
rule literally but by doing so, introduced a big performance problem in the
application.  This is indeed unfortunate but there are better and more
standard way to address this problem than by using a static (the two most
obvious ways are to keep this information in the servlet session, or maybe a
Stateful Session bean, if your application doesn’t have a Web tier).

That being said, Bob’s entry is a must-read for anybody who has ever wondered
where these odd limitations in the EJB specification came from.