Unless I'm totally missing something, and without making any core hacks to try to modify the external user feature to be able to actually register users from Q2A, option 2 is not an option as it is not possible.
If you have a main domain with multiple sub-domains, I would expect the idea is that each sub-domain displays absolutely different questions (e.g.: the total Q/A/C displayed in the activity box would display a different number for each sub-domain). This means you will have to have different tables to store the posts (I'm using this table as an example but there are many more tables that you'll need to have exclusively for each site).
However, regarding user management you might want to store users separately for each site, which would mean you will have different user logins per site. Alternatively, you might want to have one login for a user that can be shared among all sites. Both options are possible in Q2A. The former means you'll have to setup different sites per domain (could be under the same database or not, which doesn't change performance at all) and the latter means you'll have many sites setup in the same database (which doesn't mean they will be using the same tables).
Expanding the idea of having shared users in the same database, this is achieved in a very simple way: you have to setup different sites that will all connect to the same database. Note each site will need to have a different posts table so each site will have to have their own table prefix so that they don't mix posts data between sites. However, the idea is to actually mix user data so, apart from changing the QA_MYSQL_TABLE_PREFIX it will be needed to change the QA_MYSQL_USERS_PREFIX. All sites will need to have the latter constant defined with the same value so that all sites access the same user data tables.
You're talking about advantages and disadvantages. However, I think the two approaches tackle so different issues that thinking if it is more or less performant should be beyond discussion, as there is only one option for each user management approach. Still, sharing the same users table will lock it more often. Depending on how big the sites are this might be an issue or not (I hardly believe someone here has a site that big for this to actually be noticed).
BTW, database size is something you shouldn't care at all. You should care more about row amount for each table. The more rows you have the more time you'll spend searching and the more time you will spend maintaining the index after modifying indexed data. Having all users from multiple sites in the same table will, of course, increase the amount of rows that it will store.