It makes sense that if it’s faster to use a new table for a thousand entries, it must also be faster for tens or hundreds of entries.
Performance is not about the pure number rows – the real amount of data and their structure counts. Usually, you use just the theme mod API. Your theme data is on a predictable place and can easily exported or changed by plugins. The theme mod API stores all data in one single option, so a cluttered options table will not be your problem.
But if you put very deep arrays or objects in your theme data the (de-)serialization may slow down reading and writing these options. I’d rather work on my data structures in this case than creating a new table. And I’d use a good caching plugin to decrease database queries.
If you opt for separate tables – find a good solution for child themes and multi site installations. Imagine a small network with 100 blogs. Do you create a new table for each blog? Or do all blogs share one table?
I would use a separate table only if WordPress’ table schema could not map my data structure. In a theme this is probably not the case.