Well, it is going to be hard for me to debug your code if you give me data that doesn't exhibit the problem you describe. You should really try to extract the smallest data set that causes the problem and work from there.

I have a few comment son your code, but nothing that should prevent it from working:

• instead of wrapping the creation of the twig and the parse in an eval, you could create the twig normally, then use safe_parsefile, and test $@ to see if the parse succeeded,
• if you use a recent (3.00 or above) version of XML::Twig and of Perl (5.6.0 or above) with Scalar::Util then the purge/dispose/undef dance is essentially useless. At the end of the block the object is destroyed. Correct me if I am wrong and I will fix it ;--)
• $objnode->children( q{message[@id]}) is probably faster, and simpler, than using a full blown $objnode->get_xpath( q(./message[@id])),
• nothing in the docs tells you that $node->{att}->{'id'} is a valid way to access the attributes id. Only $node->att( 'id') is garanteed to work in future releases (sorry, that's a pet peeve of mine, I know that the doc is quite overwhelming and that the attributes are indeed stored in a hash, but users breaking the OO model here prevents me for example to pool attribute values, which could decrease the memory needed to process some documents).