Q3) Is it considered best practice to create your own tables rather than adding fields to existing tables "belonging" to other modules?
definitely! the other module might alter the schema and your data could be destroyed.
for example, sometimes, the best way to add a new (computed) column is to create a new table with the schema you need, populate it with fancy SELECT logic, and then drop the old one[1]. if your contrib has hidden its own columns in the original table, the author of the schema update won't know about your columns and will blindly drop all your data after safely migrating their own columns to the new table.
-derek (dww)
i'll agree with dww that this is best practice for Contrib. But for a custom site, I think hook_schema_alter() is a terrific way to add columns to tables owned by other modules. this avoids joins, which can be very useful for improving performance. many core objects now use drupal_write_record() to write their data to the database and that function is designed to work with altered tables like this. In other words, core is deliberately moving towards allowing custom fields attached to "foreign" tables. We do need to some conventions for safe update functions so we avoid a scenario like dww describes.