I don't know if one particular point that Bales made was emphasized enough, even by Bales. Certainly, it was not dwelt on in Jordan's article, which is unfortunate since I think it is much more fundamental and important than is given credence by either "side".
As an admitted newbie to both JDO and the advanced sort of JDBC O/R mapping advocated by Bales, what struck me after reading both articles is the following distinction that Bales mentioned. Bales said that JDO is all about working from an entirely Java-oriented perspective regarding persistence of data and behavior, where the O/R mapping approach allows one to persist data *and* behavior without regard for the language used in the application.
I think, from my "fresh, unbiased" (read: ignorant ;-) perspective, this is an extremely important point to understand. Bales says that, in his experience, persistent data outlasts the choice of application implementation language. With that in mind, he says that we as information architects will find that, if we are modeling our business processes using object orientation, we will be better served in the future by storing behavior along with data. That way, we will not need to depend on whatever language was used to implement the object model -- the object model is available to us in the persistence mechanism. He then points out some of the neat things that Oracle offers as tools to assist us with this goal.
Please note, I am not at all sure that Bales would agree that my summary is accurate. But, FWIW, that's what I took from his article as being most important. Bales' attempt to compare and contrast with Almaer's JDO article was poorly chosen, in my opinion.
Jordan seems to have taken umbrage at Bales' attempt to assert the superiority of the O/R approach over JDO, and rebuts with three points: Bales' code is of poor quality, JDO is easier to code, and JDO has other areas of functionality not touched on by either Bales or Almaer that make it a very attractive technology to use.
I will not argue with Jordan's assessment of Bales' code -- the code is of poor quality, and the article should have been heavily edited before publication. Neither will I argue with his other points, as JDO does indeed look to be easier to code, and I am ignorant of its other capabilities.
However, I believe that both Bales and Jordan missed some things that are fundamental, but that were brought out in some of the comments that follow Bales' article. First of all, relational database support for object storage is immature. Implementation of tool support and programming approaches for utilizing stored objects is equally poor. According to one reply by Bales, Oracle has made a very good first step in this direction, and the SQL99 "standard" (my sarcasm, not his; he takes the standard seriously) mandates that all relational database vendors will be implementing these features Real Soon Now (TM). On the other hand, Chris Date has been advocating the proper use of arbitrary types for years now. His explanation is that there is no vendor support because there has been no money in it -- lack of demand for a "proper" relational database -- and his usual issue of "lack of understanding regarding the relational model".
Another point that may have been missed is that, while both JDO and O/R mapping share an area of overlap (access to persistent storage), they differ in intent (brought out, perhaps unwittingly, by Bales) and greatly in capabilities (championed by Jordan). As a result, I see different areas of use for each approach.
JDO seems to be the winner in terms of programming efficiency. The caveat is that the information model is one where data is stored persistently, but not behavior. In the event that years pass and the language of the day changes, the data will still be usable and accessible, but the apps programmers will need to reinvent all of the object behavior that is inherent in having the object model built in Java.
The downside, obviously, is that the programmers will have to reinvent the behavior. The upside is that, as time goes by, the kind of data collected tends to remain the same, while how data is used often changes. Thus, reinventing behavior is not necessarily a bad thing. In addition, the general trend in programming languages over the years has been one of increasing programmer productivity by increasing abstraction and decreasing the amount of code needed per unit of functionality (machine code, assembler, C, Java, ?Python?, ???). Thus, one can make the fairly credible assertion that, by the time it is necessary to rewrite persistent storage access code in a new whiz-bang language, the language and the state of software engineering will have evolved new tools that make such rewriting substantially more efficient and/or powerful.
On the other hand, we are seeing the debut of database systems that actually implement the feature-set that Date considers necessary for a true relational database. If such systems can ramp up to meet the needs of programmers for persistent, language-independent storage of data and its associated behaviors, and if associated tools can ramp up in efficiency and ease-of-use, and if persistent behaviors can be easily modified as business needs change, then we may well see the sort of sea-change that Bales anticipates and Date claims is necessary and long overdue.
While I think that the database vendors will inevitably meet these challenges, I do not expect it to occur any time soon. Notice I leave myself some wiggle room by avoiding defining "soon". :) As a result, I would not avoid a more efficient toolset just to jump on a bandwagon that is not yet fully mature. But I, for one, intend to keep my eyes peeled regarding the subsumption of objects (a term that Date dislikes intensely) into relational databases. As Jordan says, the power that relational data manipulation brings to the table is considerable.