Rapid prototyping should happen every time you need to add or change an abstraction. With the way many (most?) software projects work, with new feature requests and requirements appearing along the way, this happens all the time. With new requirements, the old abstraction often doesn't fit 100% anymore. Applying a few band-aids to the abstraction is probably fine, but at some point you will need to reconsider the design, or you will end up with a design that does not match the problem it's solving, making the code difficult to follow and therefore error prone.

In my experience, this need arises very frequently in complex systems with evolving requirements.

Oh, don't get me wrong. I fully agree! What I was saying is that the initial rapid prototyping of a project is happening only once.

Our company offered us to sometimes reconvene physically and discuss such things but since our team are all family men, it hasn't happened yet. But it is a really good idea and we should reconsider actually doing it sometime.

That 1% (and is often more like 5 or 10) can have big implications, but you can just have an on-site, it's a lot cheaper than having an office year round. Plus you can do it somewhere fun and it's a great perk and team building exercise.