What problems are there with the SPF ‘ptr’ mechanism?

I would say that it is slow simply because it requires multiple lookups to process; first the PTR lookup based on the connecting IP address, then confirming that response by looking up A or AAAA for the name(s) you got in the PTR result to verify that it actually matches before using the PTR result to decide the SPF outcome.

Keep in mind that SPF always boils down to specifying a list of allowed IP addresses that a recipient can use to judge whether the incoming mail is being delivered by a legitimate host, and as such the ideal SPF mechanisms are ip4/ip6.
All the other mechanisms are just indirections that provides some degree of convenience for the SPF publisher at the cost of efficiency for the email recipient; hence why there is a limit of 10 lookups from these indirections to enforce some balance by limiting the cost for the recipient of verifying an incoming email.

Note that the particular case of the ptr SPF mechanism is an indirection where the publisher of the SPF record does not even know what sequence of lookups they are asking the email recipient to perform (as the initial lookup is based on the connecting IP address!). This in my opinion makes it extra problematic both for speed and reliability.

As for the burden on the .arpa nameservers, having a mechanism that induces more lookups as part of the mail delivery process would obviously increase it, but it's hard to judge how much of a problem that might be in practice compared to all the other reverse lookups made for other reasons.