It depends entirely on what exceptions you decide to throw. I'm assuming your session bean defines your business methods. If that is the case, it probably makes sense to limit possible exceptions these methods can throw to exceptions which have meaning to the functionallity the method is there to perform.
Your DAO layer for example is likely to generate JDBC-type exceptions. But is it appropriate to throw these exceptions from the Session bean? What does a client care that it was a primary key constrain violation, or a invalid number of bound parameters etc. which prevented it creating some type of object in the DB? As far as the client is concerned the operation either works or doesn't, and there's nothing the user can do to fix it, whatever flavour of JDBC-type exception was thrown from the failed operation. Instead you might have your DAO layer throw one type of DAO exception with a simple message, and log the real cause so you can address it.
Application exceptions are checked exceptions, so the container will pass them back untouched to the client.
But bear in mind that some low-level exceptions like SQLException are checked but are unlikely to be welcomed by the client. In such a case, wrap the exceptions in javax.ejb.javax.ejb.EJBException and throw it. The container will catch the exception, log it and throw EJBException to a local client or java.rmi.RemoteException (or subclass thereof) to a remote client or web service client.