From R. Monson-Haefel's book on EJB I understand, that EJB clients that are EJB's themselves, use a somewhat different (namingcontext-)lookup method than 'regular' clients. But why ?
Created May 4, 2012
As an example, suppose an industry group defined a set of standard EJB interfaces for, say, HR applications. Different vendors would implement EJB suites that implemented these interfaces, and J2EE applications that used them. If the beans were written using the <ejb-ref> tag, rather than 'knowing' one another's JNDI names (which can be done, by the way), you could, theoretically, mix and match EJBs and applications to build a solution that best fits your company, simply by changing mappings. Of course, this is theoretical: at this stage of the technology, I'd be really surprised if everyone involved actually did things 'right'.
The java:comp/env namespace was put into the 1.1 spec to simplify this and a couple of other things. Putting all of these mappable elements under a consistent JNDI context helps to ensure interoperability by encouraging consistency. Note that this can also be used for things like global settings for a bean (say a threshold of change to a salary that may only be done by someone in the 'HR Manager' role).
This all makes the most sense when you remember that EJB (and J2EE as a whole) is a Component specification: since each of these things is a component, it should be configurable to work with other components without code changes.
Note also that recent J2EE specs have implied that the client should be getting references in much the same way. In fact, the 1.3 spec (available from javasoft.com as a public draft) indicates that the application client deployment descriptor can include <ejb-ref> stanzas