Very good, especially given perforce's competition (cvs, svn, etc) over most of its life, but no, not as good as Git. I can't speak to hg.
While some of this is off-base (the p4 shelf is now an old feature, no, you can't make a dvcs behave just like a vcs, and it seems silly to knock p4 for xcode dropping support) the choice bits about p4 merging headaches are accurate.
I don't think there's anything inherent to a distributed version control system that makes its merging naturally superior to a centralized system like perforce. Rather, the data models adopted by many dvcs's lend themselves to superior branch and merge tracking.
Perforce branch mappings? A cumbersome alternative to git's pointers and directed graph approach.
One key advantage of git over perforce -- tracking code through refactoring -- has nothing to do with git's status as a distributed version control, but rather the fact that it looks at both files and blobs of content as first class citizens in its data model. This is completely different from perforce, which keeps extensive metadata in its database on a file-by-file level: file state, history, attributes, changelists, while versioned file content is stored separately in a filesystem hierarchy.
Lastly, and this may be a bit unfair but I feel that if a version control system needs to have a file locking feature, it probably doesn't bode well for its branching and merging sophistication.
For a biased comparison of git vs. perforce (archived link). I also find it telling that perforce has itself jumped on the gitwagon.