Perltidy predates PBP by a long time. Perltidy is a bit of a huge mess, and it has its own parsing code and is nearly impossible to hack on. We really need a PPI-based re-implementation.
There was a very interesting submission to HN on why code formatting utilities aren't easy things to write, [0] called, The Hardest Program I've Ever Written [1]
The code of Perl Tidy at least looks pretty good! [2]. Perhaps there's a reason why PPI isn't used, that I'm not famliar with, other than - as you say, it predates it. Perl::Critic uses PPI, yes?
For the longest time Perl was considered unparsable, primarily due to the two features of function parens being optional, and the argument-slurpiness of function calls being unknowable without introspecting the function reference that ends up being the final one, at runtime. In the most famous example this can lead to a / after a function call being considered either the division operator or the start of a regex; with both interpretations resulting in valid Perl code. It took a while for anyone to come up with a schema in which Perl could be parsed while also being round-trippable. It took PPI a while to get there and be stable, and meanwhile P::T had already become stable itself.
