IMO in many cases RDBMS are better choice for persisting data. And sometimes LDAP, and sometimes filesystem, and sometimes plain text.
I don't disagree that they might be more stable ways of persisting it right now, due to the investment of billions of dollars and time by RDBMS vendors. But I disagree that it's a better choice of persisting data. Just like OO databases where always a better choice of persisting objects, XML databases are better for persisting XML. OO databases didn't make it to mass adaption not due to the fact the RDBMS was a better choice, but rather because of some not so good decisions and directions that where taken by groups/companies embracing it. One of them was the fact that they didn't standardized query language like SQL to relational. Yes, there was OQL, but it was never fully finilized/implemented.
POJOs of other lean data structures (CORBA, ICE, and alike) make very good communication medium.
Yes, and so did EDI at one time. There were many good technologies that had their own benefits that never truly where adapter by the masses, though CORBA came pretty close). Binary storage formats where also pretty popular at one point, but even Microsoft is now storing their Word, Excel, etc... data in XML. I guess the interoperability benefits beat the incremental efficiency.
You mistakenly equate SOA to XML based SOA implementation. There are other ways to implement SOA: CORBA, RMI, Jini, Grid technologies.
I don't, I think you're misunderstanding the benefits of XML technologies. It's not about whether it's efficient, better, etc..., it's the fact that it has been embraced and standardized upon by most vendors and technologies, though finally giving us a common communicatin medium that you can bet is most likely supported by some other vendor in one shape or another. XML standars have come a long way to finally providing a common communication medium that no other technology really ever did across industry standards.
Why marshal to XML if DataStructure can be transferred by other means?
It's not about senselessly (un)marshaling, but rather abiding by your data model. If your data model is better represented in a hierarchical manner, than XML is your way to go, IMO. Also if your application requires to abide by some current industry standard that is represented in XML for interoperability, why use a relational store add another level of marshaling, since you would have to represent that data as XML at one point or another anyways.
XML is not silver bullet. Can we agree on that?
I never said it was. You might be misunderstanding me again. I'm not saying drop relational stores, rather I'm saying if your application currently represents it's domain model in XML, why add another impedance mismatch and now also have to support it as a relational structure.
"dynamic hierarchical model" sounds almost like oxymoron. Dawn of hierarchical databases was caused by their rigidness. I would say that rigidness is endemic to hierarchy of any kind.
Why does it sound like an oxymoron? When you can have dynamic hierarchies within a strict hierarchy, etc... If your application needs to support it, why fight it?
Say you have a non-predetermined model that allows dynamic configureation of state, basically fully dynamic objects, not predetermined at compile time. A good example of that would be, dynamic forms that are configured at runtime, and have to be typed. Forms, might even have subforms, etc... (composition), and all is dynamic, and they all have to enforce foreign key relationship integrity. In a relational world, it's mostly represented as a huge table, that would keep the attribute name, value, it would not be strongly typed. Doesn't fit into the rectangular model very well, does it. Of course it can be done. You can also store XML in an OO database, and relational data in an XML database. You can write huge programs in a procedural language, just as you can in OO. All I'm saying here is that all data models do not fit the relational structure and if it doesn't, why fight to fit it in there.