I think a more likely explanation (vs. theories about macro usage) is that the programmers weren't fully familiar with the intricacies, or it was effectively "learned behaviour" (think: habit). Occam's razor applies. I'll try to explain my view of it more verbosely:
I've several 65xx books and most of them do not go over clearly/concisely, in a programmer-friendly fashion, the "behaviour" of interrupts as far as P (status register) goes. The Lichty/Eyes book has an entire chapter dedicated to interrupts, but doesn't explain this unless you really dig (it's deep within a long paragraph, and not clearly demonstrated, thus very easily overlooked), nor do any of the other 65xx books I own (many of which were published during the CPUs heyday) denote this aspect in a way. The only one I have which does is "6502 Assembly Language Programming" from Lance A. Leventhal, circa 1979, and is clear about it -- but it's smack dab mid-chapter (the interrupts chapter is 40 pages long), covered in a couple lines. In contrast, the book "Programming the 6502" from Rodnay Zaks (circa 1983) doesn't really go over this either, at least not clearly/concisely. I can provide quotes from all these books on the subject if asked, but that borders on obsessive-compulsive. (And yes, I DID actually pull said books from my library and review them)
In other words, bare minimum it's something easily overlooked/forgotten, bordering almost on "tribal knowledge" in a sense (cut me some slack).
Now add the following into the mix: Nintendo up to that point, to my knowledge, had little-to-no experience with the 6502 CPU.
Here's a reference for that. They went looking at arcade systems when they chose to go with the 6502.
...then consider what the state of 6502 documentation in Japanese may have been at that time.
...and let's also not forget Metroid was a first-generation NES game.
There's a lot of things in NES games in general that induce "what the heck?" reactions when code reviewed. I'm sure if you were to review some of my code from my youth you'd find similar mistakes or oddities.