Maybe because ... planned for perl6.

Damn man! Way to go, twisting history in your attempt to make a puerile point of no consequence and extremely dubious value. I think you just proved everything dave_the_m said about you. And more.

Perl has undefined subroutine argument evaluation order because C had undefined subroutine argument evaluation order.

And C had it, because when C was defined, the plethora of cpu architectures, with weird and different instruction sets -- RISC, CISC, orthogonal and irregular, 8-bit, 16-bit, 18-bit et al. -- combined with no pipelining, no branch prediction and many clock-cycles for even the simplest of instructions -- giving what by today's standards was absolutely glacial performance -- meant that specifying it one way might be optimal for one architecture, but lead to the worst possible performance on another.

Hence, is was a conscious design decision by K&R to leave it to the implementors of compilers, despite that they acknowledged that it detracted from the generality of the language, placing the onus on the human programmer to avoid, otherwise legal language constructs that were ambiguous -- like the classic: func( a++, ++a );

It was an expedient compromise to the realisation that 'the hardware problem' was beyond the control of programmers and their software.

outlaw any possible parallelization effort ...

That's just garbage. Though in your defense, it is widely misunderstood and disseminated garbage.

A defined evaluation order -- not just subroutine args, but also subexpressions -- would enable the programmer to make informed choices at the source level that would vastly enhance the potential for parallelisation.

It all comes from LISP, which is the only other language which left it undefined,

And that's just plain wrong! Glaringly, verifiably, obviously, wrong.