I think your best bet is to stay with the current location and link the existing org. As you point out you will loose upgradability for your existing customers. And migrating them will involve (depending on the number of custom objects and dependencies they have elsewhere in their orgs) quite complex and not great from a customer perspective.
In reality while you get 20 users, having 20 developers developing in one org is not really practical. One factor is the daily API usage starts to burn a lot more quickly. Once you get above 1 or 2 and/or more complex code base and multiple releases you probably need to move out all together and into a more source control centered solution. Using your packaging org mainly as a release tool at that point.
Finally if there are aspects of the Partner DE orgs you want in your existing org, you will most likely be able to get SF support to match them if you ask. Unless there is some aspect I'm not aware, there is not a great deal of difference.
TL;DR - Marking the validation rules as inactive prevents them being countered against the spanning relationships limit during managed package install.
After install they can be activated one at a time until the limit is reached.
Results based on @Ralphs suggestions
Experiment 1: Dev Org with 5 active validation rules on Opportunity. Install managed package with 7 active validation rules on Opportunity
Result: Install fails with 2 Spanning relationship limit exceeded errors
Experiment 2: Dev Org with 4 active validation rules on Opportunity and 1 inactive. Install managed package with 7 active validation rules on Opportunity
Result: Install fails with 1 Spanning relationship limit exceeded error
Experiment 3: Dev Org with 3 active validation rules on Opportunity and 2 inactive. Install managed package with 7 active validation rules on Opportunity
Result: Install succeeds. Attempting to reactive one of the local inactive validation rules gives the message:
Validation Errors While Saving Record(s)
There were custom validation error(s) encountered while saving the affected record(s). The first validation error encountered was "The formula references fields across 11 relationships while only 10 are allowed. Please contact support at salesforce.com for more assistance.".
Experiment 4: Dev Org with 5 active validation rules on Opportunity. Install managed package with 6 active validation rules on Opportunity and 4 inactive.
Result: Install fails with 'The first validation error encountered was "The formula references fields across 11 relationships while only 10 are allowed. Please contact support at salesforce.com for more assistance."'.
Experiment 5: Dev Org with 5 active validation rules on Opportunity. Install managed package with 0 active validation rules on Opportunity and 10 inactive.
Result: Install succeeds. I'm able to manually active the validation rules from the managed package in the client org until the limit is reached.
Best Answer
Yep. It can also fail push upgrades for extra confusion if both you and the subscriber have created dynamic dashboards.
Yep. Because the dynamic dashboard limit is not namespace-scoped, including them in a managed package is an anti-pattern unless you control all of the environments in which the package will be installed. If necessary, deliver the dynamic dashboards in a separate extension package that subscribers can choose to install or not install.