Sigh, that example from Perldocs is (as I dimly remember), a translation of old C idioms.
I don't know what you try to prove by bringing up some trivially bad code examples.
(I am not certain about the order the shifts would be evaluated, if I wrote code like that. An attitude from my old C days, since you can trust Perl's eval order. But I got what the pos code did.)
Though, I have come across code that used those idioms from the Perl docs. The code that it was buried in looked like it was someone that didn't know Perl very well and was probably just copying from the docs. E.g. everything had a function prototype, which is something I've rarely come across even in 'cute' Perl code.
Perl Best Practices isn't a new book. Pervasive testing took over the (Perl) world a decade ago. There are lots of people doing serious development with Perl.
But that kind of code won't go away, since Perl is a system administration language. It will be the first language lots of people use for fixing things in their file systems, batch download of web pages, etc. Such code will never be pretty. And there is nothing wrong with that.
And btw, I'd use one of the many CPAN modules for fork/exec, but if I was in a hurry I'd copy the Perldoc example. It is a standard idiom in the Unix world.
I don't know what you try to prove by bringing up some trivially bad code examples.
(I am not certain about the order the shifts would be evaluated, if I wrote code like that. An attitude from my old C days, since you can trust Perl's eval order. But I got what the pos code did.)