Ah, this one makes sense to me. If your bean uses another bean to do its work, it doesn't necessarily need to know the JNDI name. There can be an <ejb-ref> stanza in the deployment descriptor, which puts a reference to the second bean in the first bean's special environment. That means the first bean can look up the second bean in JNDI using "java:comp/env/ejb/MyHelperBean" rather than the actual JNDI name of the deployed bean. That's useful because the bean provider (who writes the code) is not supposed to know the deploy names of the other beans. The bean provider just has to come up with a name like MyHelper bean, write the <ejb-ref> stanza, and let the application assembler add the <ejb-link> tag to it to refer to a real deployed bean, which can be in the same DD or another one.
The best practice is to use a level of indirection when doing JNDI lookups. Remember, the Bean Provider is not supposed to know anything about the target live environment. So, use of ejb-link without specifying a global JNDI name for the bean is good practice. In this case, the bean is accessible only via ejb-link.
Also acceptable is to declare a global JNDI name in the server-specific DD file, and have the caller use either an ejb-ref or an ejb-link to link to that JNDI name.
Least acceptable to declare a global JNDI name and have your client lookup that name. This means a lookup of the real JNDI name with no level of indirection. If the JNDI name were to change, perhaps due to a move to a different server, you would need to change the bean code.