Without having done any testing, I think that one of the important considerations here would be "what kind of personalization conditions will cause performance impacts?" The rules engine is very performant in general, so it's really the performance of the individual conditions that would matter.
Some personalization conditions would be relatively lightweight. For instance,
Sitecore.Rules.Conditions.DateTimeConditions.NowCondition simply parses a
DateTime string and compares it to the current datetime. Compared to the rendering of a normal page, this would have a negligible impact.
On the other hand, some of the xDB conditions would be comparatively more expensive to compute. For instance,
Sitecore.Analytics.Rules.Conditions.CampaignWasTriggeredDuringPastOrCurrentInteractionCondition needs to lookup the previous interactions (which is, then, cached) and then evaluate if any of them had a specific campaign triggered. This could cause an xConnect or Mongo call depending on the situation, which could add milliseconds to the request. Still likely low compared to a full request, but the right combination of these could be bad.
Additionally, some custom conditions may be more or less performant, so those should be taken into consideration as well.
My recommendation is that if this is a concern, read through the common conditions and produce a spreadsheet for your editors of the likely performance impact of each one based on what each one has to do. Then, you could produce some recommendations for them, such as "only use up to 5 of these conditions but you can have as many of these conditions as you like.
As an aside, with regards to your point around zip code rules, the postal code rule in Sitecore does a string comparison on the
Sitecore.Analytics.Tracker.Current.Session.Interaction.GeoData.PostalCode property. If you only care about zip codes, I would write a custom
Sitecore.Rules.Conditions.IntegerComparisonCondition which parses the postal code property and does an integer comparison. This way you could compare to blocks of zip codes instead of individual ones, potentially reducing the number of comparisons to a reasonable amount.