1. Performance is typically hindered quicker by rows of data than the columns themselves. The beauty of rules is building the exact queries needed so you dont need to worry about the erroneous columns when actually executing the rules. In general though, the more data you return the worse the performance but again your row limit is significantly higher than the column limit so that will be the larger factor

2. You can query as many rules (tables) that you want from within a form, again operating under the same principals as #1 the more data you return the slower it will be. You also need to be aware of the "waterfall" affect when you have lookups that trigger other lookups. Sometimes its unavoidable but its something to keep in mind when designing your forms

2b. You typically want to update your tables from within workflow and not on the form itself. It is easier to establish your data's integrity when the form has been submitted than if a user is still changing data on the form itself. You unfortunately cannot update more than one table at a time for now though so you would need at least a 1:1 ratio of rules to tables when updating information. If you have common tables that should be updated at the same time I would pull those into their own workflow so you can invoke that workflow from any process and make sure all associated tables are updated properly instead of attempting to replicate the same logic in many places