Additionally, CPython's gc is also only eager in a best effort kind of way. If cycles are involved it can take long to release memory. This will become even more the case in future versions of CPython, in the free threading variants.
The question isn't even whether or not you "should" write PyPy-friendly code, it's whether YOU DID, or your predecessors did. And the answer is "No, they didn't". I mean, duh, as it were.
PyPy isn't compatible. In this way and a thousand tiny others. It's not really "Python" in a measurable and important way. And projects that are making new decisions for what to pick as an implementation language for the evolution of their Python code have, let's be blunt, much better options than PyPy anyway.
Again, that's a proscription for how to write python code for future execution. It's emphatically not a statement for the behavior expected by python code already in production, which tends to rely on this behavior (along with many other such warts and subtleties) implicitly.
And the fact that PyPy doesn't feel the need to clone it (and all the others) explains why PyPy basically doesn't work for existing python code.
I mean, me being an idiot python developer in your eyes does nothing to make the ancient code I received run. It just makes you feel smarter. That's a bad trade.
PyPy needs to be compatible before anyone is going to use it. And it isn't. And so people didn't. And so now it's basically dying as no one wants to work on a project no one uses.