If it is a checked exception, from which the bean cannot recover, throw the exception as it is.
In such a case, the bean provider must ensure that the transaction is never committed and the instance is discarded. To achieve that he must throw a system exception. This can be done by wrapping the exception into an EJBException and rethrowing it. EJBException is a system exception and this will ensure that the transaction will never be committed and instance will be discarded.
If you throw the checked exception as it is (if it is listed in the throws clause), transaction will not be automatically set for a rollback and there is a possibility that the client my still try to commit it.
This is muddying the waters by using checked exception and system exception. Table 15 of the ejb spec specifies AppException and "all other exceptions". Table 15 also specifies only Appexceptions as to be re-thrown as-is to the client. Considering that an appexception is a checked exception (because system exceptions are runtime exceptions), then it looks very much like this answer is correct.
Furthermore, instance discard, logging and transaction (if one exists) rollback occur with system exceptions, which are not checked exceptions, so the first line of the explanation does not make sense:
"In such a case [checked exception ie appexception], the bean provider must ensure that the transaction is never committed and the instance is discarded."
How can that not be the case?