So, what you say is:
I don't care to implement an efficient solution, because the CPU cache will fix it anyway.
That way of thinking is well known as "The Java way of problem solving" (TM)
For the use case required by ZeroMQ, it's faster in all cases, because swap-with-last and shrink is O(1). Sure, if CPUs didn't have caches, a list might be faster.
Do you see where this is going? The C way of solving problems consists of adding one more level of indirection (ever heard of 3-star C programmers?), because it becomes more efficient asymptotically that way. Nevermind the hidden factor of 100-1000 due to pipeline stalls and cache misses.
Fortunately not all C programmers think that way.