I'd agree that XML::Twig is purpose-built for reading in "twigging the data" and writing back out again.

There is a monk here somewhere whose signature is something like, "Don't write your own XML parser." But of all the scores of languages I have ever seen, I have found XML to be absolutely the easiest to write a parser for. As far as your needs are concerned, the Backus Naur Form (BNF) is the shortest I can imagine for a language. Something like this would about cover it:

Document :== Heading [Tag ... ]
Heading :== "<" [!">" ...] ">"
Tag :== "<" { TagName [Assignment ...]} ">" {Value|Substructure} "</" 
+Tagname ">"
Value :== [!"</" ...]
Substructure :== [Tag...]
Assignment :== name "=" QuotedString
[download]

guaranteeing that the parser (which does nothing other than express the BNF in code form) should be as trivial as it gets.

Of course, you also need a lexical analyser - about half a page in Perl and a thrower to walk past whitespace and carriiage returns, which can also poll the lexer rather than be written from scratch. You would also need to choose a structure that differentiates between simple value tags and tags that contain a substructure (e.g. tagname => { VALUE => scalar } versus tagname => { SUBTAGS => arrayReference }).

The code generation is a mirror of the parser, reading through your datastructure and generating the appropriate XML - thus equally trivial. You need to track the recursion depth of the puttag routine and just multiply $tabsize*($depth - 1) X " " to indent, putting each tag on its own line.

But the case for writing your own parser actually depends on whether or not you have a continuing need to meet new requirements that you cannot predict in advance (in my case there are multiple streams of XML to and from different organisations that have to be addressed for a single system) and cannot therefore nail your colours to any particular module that might already be available.