Want to see someting utterly insane? How about backwards SAX-style XML parsing. Yes, that is insane. Surely, the simple answer is to use SAX to parse the whole document as a stream and use an attribute in the root child element to specify the piece of data you want, and then take that particular chunk and load that in to a tree parser like DOM. 
There may be performance hacks that could merit this type of approach, but the idea of using this approach as a method to implement a key feature in an application is absurd and insane.
A neat hack I found recently with writing an XSLT-based microformats parsing system in PHP5 is to use regular expressions to search a document. Basically, I have an XSL stylesheet to convert, say, hCards in to RDF/XML. But there's no point in going through the process of spawning an XSLT processor or loading the stylesheet in to the DOM if there are no hCards in the document. A regular expression just looking for the word "vcard" rules out the vast majority of documents that don't contain hCards. It's just an eliminative process to increase performance and reduce server load.
It's not pure XML though. When XProc comes in to vogue, I'm not sure what we can replace such hacks with. Perhaps you could do it with XSL by using regular expressions to invoke external stylesheets. I'm betting that such a hack wouldn't be particularly efficient.
I like the idea that M. David Peterson puts in the comments of producing an XML Best Practices specification, although I'm pretty sure I wouldn't contribute to such a specification - my best practices are snark-filled and evil.
The only rule of XML Best Practice is "Actually goddamn use XML!" - a rule that our friends at both the W3C and the WhatWG ought to tattoo backwards on their forehead.
