In general, JNDI searches are performed when you are in a context that does not support injection.
If you are in a context that exists, there are several more reasons. One of them is that the bean that you enter will be serialized and does not know how to re-enter again after de-serialization (this happens for built-in JSF managed beans when using state on the client).
This last reason may be the reason the teacher had in mind. The beans session can be passivated (after which they will be serialized), and you may not want to serialize the embedded resource in some cases. In this case, you will not store the resource in the instance variable, but you will request a new one from JNDI every time you need it.
Another reason is that with JNDI you can programmatically decide which bean to get, but this does not apply to the beans state session and is performed for all types of injections anywhere.
Note that the above is mainly about entering an INTO session with a bean state. As Milleienus correctly states, there is also the question of introducing a session with a bean state into something. If you also do not assign an area for SFSB (via CDI @SessionScope, @RequestScope, etc.), then injecting into a servlet or other shared resource (for example, controlled by the bean application) will expose the same SFSB for all users which you most likely don’t want.
If you cannot use CDI (for example, maybe you just don’t know that it exists), then getting SFSB through JNDI is a workaround. If you want to keep the state longer than one method call, you will need to store it somewhere, for example, in an HTTP session.