It's also a major argument in terms of stability to just use the precompiled, tested binaries that everyone else is using.

There's merit in that approach.
Personally, I don't like that a 64-bit perl automatically "upgrades" integer values that exceed 64-bits by rounding them to a 53-bit precision NV (often with loss of information). If you have the option to instead use a perl that automatically upgrades integer values that exceed 64-bits by setting them to a 113-bit precision NV (and guaranteed no loss of information, unless they exceed 113 bits), then I think it makes good sense to avail yourself of that option.

Effectively, with 113-bit NVs you've got 113-bit integer arithmetic so long as the operands and the result are in the (integer) range of -10384593717069655257060992658440191..10384593717069655257060992658440191, even on perls with 32-bit IVs..
(Some caveats - with division you'd have to int() the result, and the left shift and right shift operators don't work as intended. But '+', '-', '*', and '%' work fine.)
In any case, it's the fact that a quadmath perl's native arithmetic avoids that "loss of information" that appeals to me - rather than any extended integer arithmetic potential.

I can envisage that many perl users don't care about that and would prefer the comfort of the 'double' NV, even though it's comparatively lame.
And, of course, some systems are so lame as to not even provide the option of a 113-bit precision NV, anyway. (I guess that the 64-bit precision long double is then also an improvement, but not one that I would bother with unless the IV is 32-bit.)

Cheers,
Rob