When we were looking at migrating from Makefiles to Ant scripts, we realized some of the problems Maven is trying to resolve. At that point (about 2 years ago), there was no Maven or Centipede. Gump was just getting started.
We took pretty much the exact route you advocated - an XSLT wrapper around a POM that transformed it into an Ant buildfile.
That approach works great for the 90% that's the same from project to project. The POM covers about 8% that differs from project to project. Unfortunately, there's always the 2% difference from one project to the next that's just unaccounted for. That's where Maven's pre- and post-processing goals excel - filling that 2% in.
And then there's the whole repository thing. To be sure, you could probably implement a JAR repository using Ant's get task, and utilizing the version info in your POM to dynamically generate the get tasks for that specific project. But you know what? That's a lot of hard work! I should know, since I'm adding that to our home-grown system right now.
Same thing with the web site generation. We also added that to our system, utilizing XSLT and Ant tasks. But it's also a lot of re-inventing the wheel that Maven's already done.
Finally, there's XSLT itself. XSLT is just not all that robust a programming/scripting language. Some of the processes I've had to implement to make the build file templating work are just plain ugly.
And therein lies my one beef with the Maven project - the choice of Jelly as a scripting language. From my viewpoint, XML is for data. It was never meant to be a scripting language, and is far to verbose for that. There is a natural synergy or flow when you combine Jelly with Ant, so I can understand why they made the choice, and in the end it's just a matter of opinion.
Once they've got a stable 1.0 release, I'll be looking forward to easing my development and support burden for our homegrown system and switching over to Maven.