If there is a performance or extensibility benefit to JDO over an Entity Bean solution, JDO may still be a better choice, but in our situation, I think that the work required is going to be about the same- you're going to have to do the R to O mapping somewhere.
I think that the benefits of JDO over EB are in the transparency of the persistence, rather than a difference in the amount of work required to state the mapping. For instance, JDO allows persistent classes to be part of an inheritance hierarchy, so that a query can return a heterogeneous collection of concrete subclasses of an abstract class, as long as the query condition can be expressed in terms of persistent fields of the abstract base class. I believe that EJB2.0 can't do this.
As far as performnace goes, I think performance depends on the implementation for both JDO and EB. In any case a lot of performance depends on having sensibly sized transactions and choosing the right isolation level whatever access technology you use.
However, I don't see the database people letting their expertise be replaced by an algorithm written somewhere else.
I'm sure you're right -- I'm lucky, I don't have any 'database people' :-). I think you could make a case for using the default JDO generated schema during development and then designing and mapping the final schema as parts of your object model stabilise -- there's no reason why you can't have a partially automatically generated and partially manually mapped schema.