Logically, the memory manager would find the same free block the second time around as the first since nothing changed.

Not necessarily; plenty of garbage collectors try to make object creation as cheap as possible, so the memory manager could allocate a new SV header out of the same pool every time (bumping up the pointer to the next free object in the pool by one unit every time) instead of maintaining a free list of SV headers. If you can get a copying/compacting collector to work correctly (moving headers can be somewhat tricky if you don't want to stop the world), you avoid mucking with a free list. In my experience with Parrot, you actually lose time with the free list games when you malloc() a new pool and have to stuff every header there into the free list.

Granted, Perl 5 doesn't do any of this, and your analysis of what happens, why this isn't an optimization, and why hipowls's comment absolutely baffled me is completely correct.

Still, speaking "logically" about a memory manager isn't always necessarily possible. There's a lot of subtlety possible there. (I didn't even mention the cache SV attached to some ops in Perl 5.)