What are the advantages and inconveniences of generalization or specialization of SQL tables?
Solution A is a bad solution if you have to add columns in future.
Using alter table in production environment is discouraged. Can hold the
database because of locks needed. This could not be a problem, but it really depend on the number of rows and concurrent transactions.
On the other hand is very simple to retrieve data, is a sort of denormalization,
so no join imply fast response time.

Solutions B and C are two similar desings. I dont like them. You wont be able to have cumulative 
data (count(1), group by..) in a single statement. You still have the problem above, if you need to
add columns. But now this problem is repeated 3 o 4 times, compared to solution A. Not good.

There is a 4th solution, using a table for key/value. In this scenario you have a big table whith
only the common columns, and a second table whith the following fields:

id / bigtable_id (references bigtable primary key) / key / value

Key column will store fields which apply only to certain type of tire coupled whith its value.
For example there could be rows like:

id ==> 1 /bigtable_id ==> whatever needed /key ==> grade   /value ==> A

id ==> 2 /bigtable_id ==> whatever needed /key ==> g-value /value ==> 71

There is an one-to-many relationship between tables.
This is the solution I have seen most of the time. Is simple to manage, no need to alter table:
if you need a new field just add new record/records. 

In my opinion the fact that mix label is uncommon, is a secondary issue in design. If the problem
is the number of rows, you can use partitions and subpartitions, but I prefer have the DB desing in 
order. Of course this is only my way to see order   ;)

my 2 cent