1. Constantising parameter access.
2. Removal of temporary variable usage.
3. Common sub-expression elimination.
4. Re-coding of if, for(;;), while statements into their modifier forms
5. Merging of consecutive loops and/or nested loops into single loops or grep or map forms.
6. Moving invarient expressions, sub-expressions and statements from inside loops to outside.
7. In two cases only, manually in-lining two trivial functions where they are called in only one place and (IMO) served no purpose by way of clarification of the code and where therefore pure overhead.

My opinions:

1. Definitely a microoptimization. No need to debate this one I believe.
2. Not really a microoptimization in the sense that I'd do it for better maintainability.
3. Definitely not a microoptimization. May increase maintainability or may not, depends on the case. Good names for any temporaries introduced are crucial.
4. A microoptimization, but I'd usually do it for better maintainability anyway. The fewer levels of indentation the better, as a rule of thumb.
5. A "real" optimization. Usually lets you fold up duplicate logic and thus also improve maintainability, as such, "refactoring" in my book.
6. Dito.
7. Probably microoptimization more so than refactoring for clarity, but the line is thin here.

Basically, it's all in your definition of "microoptimization". Of all the changes I believe that your @_ parameter access is the only real microoptimization in the sense that it can't be justified by maintainability concerns. I do concur that using constants in that case is a good way to keep confusion in maintenance to a minimum, although I would still only use this rarely, as it rarely matters. Just like perrin said, there's no reason to object to microoptimizations when you know that they will pay off (although tye's objection that they rarely do is true), but they're generally frowned upon because people just blindly go in and create a maintenance problem for no confirmed reason.

I believe the payoff you're seeing here is not because of an avoided shift so much as because @_ consists of aliases rather than copies of its data, so if you directly pass down elements out of it without making a copy first, the called routine gets an alias to the same SV as you did, avoiding the repeated creation of new SVs to hold new copies. (Disclaimer: this is an educated guess.) If your program flow descends deep down through many function calls, that's obviously going to add up. IME that doesn't happen too much in practice though. Most jobs Perl is used for have relatively flat program flow.

Basically, it comes down to the right tool for the right job instead of cargo cultishly repeating "wisdoms" you picked up. Look at your situation and decide whether they apply.