Yes, there is overhead. Any level of abstraction is going to increase the performance cost of the systems. But you know this already. If you have a look at Ed Roman's 'Mastering EJB' book, there are some excellent facts about the EJB 'value proposition' that may be useful.
It is important for your client to realise that performance and scalability are not the same thing. The metaphor I like to use is that of a 1/4 mile race between a Porsche and a Dump Truck. Initially, the Porsche will always win, probably before the dump truck has really even got started. BUT, dump 100 tonnes of dirt on the vehicles and try it again. The dump truck will perform in much the same way as it always has, but the Porsche will probably be destroyed. Just hope you aren't in there at the time! As someone on Slashdot said - 'the thing with EJB is that it is consistently slow' - performance doesn't really degrade terribly as it scales.
I think there may be value in trying the two models proposed and measuring the performance and scalbility. without such a test, it is hard to be objective. Model a typical transaction of the system and implement both strategies, paying attention to how long it takes to develop! (And use container manager persistence to really speed the EJB development). Then do some load and stress testing. This way you will have a clear definition of the developmental, performance and scalability tradeofs.
As an aside, there are some patterns that do not use the full Entity Bean stack - using Stateless Session Beans can provide some of the scalability and transactional benefits of EJB without incurring the extra overhead of an Entity Bean solution. These are pretty controversial, I admit, but I have used them to great effect in certain situations.
I think that it is important to realise that this is not some newfangled idea, but the logical progression of technologies - for quite a long time, component based development has been the way to achieve scalable, transactional based systems. Corba, COM/MTS and COM+, EJB are all based on essentially the same model.
Roger Sessions (http://www.objectwatch.com
) has some interesting comparisons of EJB and COM+ that highlight the paradigm.
I agree with what you have stated - judicious of EJB gives you a whole lot of stuff for free. The cost/benfit analysis is essentially a matter of performance loss over development expense.
Interestingly, this argument:
"We would rather write our own code to access the database (via JDBC) and handle the demarcation of transactions (and rollbacks) instead of using EJBs as they introduce too much overhead."
can be extended to nearly every facet of development, it is just a matter of knowing when to stop...technically, using JDBC is a performance hit and it might be better to talk to the database on a native level. Then again, why use Java? Writing in Assembly is definitely going to increase performance...