Those who have already invested in EDI technology are not going to be in a hurry to go back to the drawing board just to leverage the latest and greatest technology. If it works, don't fix it. Those who have not yet invested in such an infrastructure, though, are far more likely to turn to XML-based technologies because the barriers to entry are so much lower.
XML-based integration technologies have some catching up to do with EDI. However, as you yourself mention, there's no reason that the experience with EDI can't be leveraged. EDI's substantial investments in business processes and vertical industry vocabularies can be directly mapped into the XML world; none of this is intrinsically tied to EDI technical infrastructures. XML enables these same things to be accomplished with much cheaper technologies and infrastructures. That means the barriers to entry are much lower, and more organizations will be able to invest in such technologies than was the case with EDI. However, one should not underestimate the amount of time and effort (and therefore cost) that must still go into such a solution. With XML, you get parsers that are free commodities, you get cheap (or free) transformation tools with XSLT, you can use your web server and simple Java programs or scripts for transport. Mapping your own business processes into standardized models and vocabularies, and working out the details of interactions with a partner, remains a large burden of work, however. XML can't improve on that.
That's why these sort of vertical, industry standard models and vocabularies are not taking off with the momentum that XML itself is. With EDI techologies, building any kind of integration interface was a great deal of work. With XML lowering the technical barriers, organizations are finding it relatively easy to design and implement a proprietary point-to-point interface with specific partners without worrying about mapping all of the specifics into some generic industry-wide model. That is often considerably cheaper and more expedient than trying to adopt some standard vocabulary.
Even before XML came along, few companies found they could standardize on a specific EDI format. The more sophisticated EDI tools included transformation engines designed to enable IT staff to build transformations mapping any format to something they can work with. These were typically very expensive tools using proprietary technologies for transformation, typically relying upon a scripting language like Tcl or Scheme for customization. The XML technologies have made this more standardized, much cheaper, and easier to implement. This has not only made XML-based standards such as ebXML more attractive than EDI (as these newer standards mature and fill in the gaps), but has made proprietary point-to-point interfaces built with these open technologies so much easier to accomplish that the whole notion of standard industry vocabularies and business process models is now less compelling.
Thus, the "XML Tower of Babel" that some lament, while others point out that it's the transformations that count (as Claude Bullard mentioned in a recent post regarding an article: http://lists.xml.org/archives/xml-dev/200104/msg00758.html). The truth is that even with EDI technologies, having the transformation tools was critical. It's just that with those tools, the transformation technology was proprietary, very expensive, and cumbersome to work with, so the role of standardized vocabularies was of comparatively greater value. If you could get everyone to agree to a standard format, you could go with a cheaper toolkit that only supported that format and alleviate a great deal of cost.