What I would probably do is to build a session bean facade that hides the database stuff. Then you have an option to use CMP or JDO or both. This is just very basic approach that has been recommended many times.
What I have found about CMP is that there are certain situations where it is not feasible. The key of using CMP is to know if your application behaves so that the database objects are cacheable. If the application behaves so that the same information is not accessed frequently, then the advantage of CMP can be lost. CMP can be slow when returning large result sets as it most likely checks the cache for each object and inserts objects to cache on top of creating objects. You can try tuning your cache to deal with some of the situations if you application server lets you.
CMP can be very good if your application repeadetly accesses same records from the DB. You could effectively avoid a database hit, avoid creation of db objects, etc. so it is very fast.
You probably know that apps are rarely behaving one way. This just means that you will most likely be using CMP AND JDBC (or JDO) to handle the exception cases where CMP does not work for you. If you use the session bean facade, then these things should be transparent to the rest of your application. Session beans give you the same transactional and security capabilities so things should work fine and you essentially lose none of the EJB basic services.
Remember that EJBs are not just CMP/BMP! When people are talking about EJB performance/scalability I never know what they are talking about. You can win when using CMP but you can also lose if you fail to understand that CMP is not for every use.