I personally don't mind the namespace choice. There are other single-letter CPAN modules too like B, L, U, V. If you have a beef with regard to namespace, don't single out P and perhaps downvote the other modules too.
Having said that, I would like to comment on the design and implementation of this module.
1) The choice of Unicode character U+2204 as representation of undef. Unless one does something like 'binmode STDOUT, ":utf8"', with 'say P undef' I am just trading one warning ("Use of uninitialized value") with another ("Wide character in say/print"). The wide character warning is avoided if you do 'P "%s", undef' though, which means...
2) P loads utf8 by default. For ultra-lightweight cases, this is sometimes not desirable. There is currently no way to turn this off.
3) The arbitrary choice of three levels deep when printing references. This can be customized but with an unusual syntax. But again, the arbitrary choice of three.
4) The "complex" rules of newline printing. p() is like puts, it can optionally add a newline. But unlike puts, the doc says it can also remove newlines. The behavior can also change if the string to be printed ends with 0x83.
I might use P for a sprintf/printf replacement, but for debugging values, I'd prefer something "dumber" like Data::Dump::Color (or Data::Printer, if that's your thing).
It is said that just because you find something useful is no reason alone to publish it. There is perhaps no better example than this module, which bills itself as an attempt to merge printf and sprintf, while saving typing and adding safety checks.
Use of this module will lead to hard to read, hard to debug code that is just not suitable for group projects, and the test failure record of this module on cpantesters is nothing short of impressive... in a bad way....
The author, I am sure, finds this helpful but for the rest of us? It is totally a useless waste of a top-level namespace.