Since plans are cheap objects, I typically create a new plan for each iteration. This also allows to go ahead some iterations or back. If you are using plan snapshots, you want to keep the plans as long as you might have a need to check it.

Another advantage of creating a new plan for each iteration is that it is often useful to add custom pages to a plan, to record information about that iteration, and you would want to keep access to those custom pages of the previous iterations (and not overwrite them with content from a later iteration).

Hi,
for me that depends very much on your iteration structure I would say.
If you have a lot of rather short and flat iterations (e.g. 2 weeks) like I currently have it for managing work, I use as well a plan that is just "current iteration" and is reassiged with every new sprint.
The need for actively viewing past iterations in my setup is very small, and we as well do not have a long planning ahead (that is managed in the backlog with tags.) I think it is important to say that we rather manage activities and not traditional work packages for development in our team.
In such a setup I have as well already used in addition an release backlog that is grouped by iteration to have an overview over the past and future iterations at a glance.
The limits: no easy access to content of past iterations. I would like to know if this can have negative effects on performance over time for what reason ever.

In a setup with longer iterations or if you reflect product releases in your iteration structure explicitely, having explicit dedicated plans at least for each release would definitely be the better solution.

As well, if I want to get a "different view" on things I always create dedicated Plans to experiment instead of just playing around with new views in an existing plan.