For the same reason Perl-5-on-Parrot has (or will have) problems running some Perl 5 modules: XS.

Some modules are partially implemented in C, and are hooked into Perl code via a combination of C macros and Perl pre-processors collectively called XS. This process relies on particulars of perl internals that pure Perl code (and pure Perl programmers) never need be aware of. Those particulars are monumentally different in Parrot.

Since the macros define a sort of API to the perl internals, replacement macros should be able to be written to create a work-alike interface into Parrot. Last time I checked, this was expected to be the major sticking point for the someday-release of 5.12, the first official Perl 5 to run on Parrot, with the old virtual machine internals ripped out and left on the trash heap. This re-macroed API is a tough job, but looks definitely do-able.

Unfortunately, some of the C code in some of those modules does *not* use the API macros; the programmer instead wrote the C code to *directly* communicate with the perl internals. This may have been for performance, ignorance, or the absence of an API macro at the time of the writing. It is these modules that are the true thorns that keep anyone from promising 100% compatibility with Perl 5 modules. Such code will require changes that only the original author might be qualified to make. Such code will also be very difficult to identify by inspection; after the replacement API macros are written, you will only know you found a XS thorn when it fails to pass its tests. Those lacking tests will only be spotted when they fail to *run* correctly.

Caveat: I've not been deep in the Parrot guts for over a year; any of this could be *completely* wrong.