To force users or administrators to have predefined list of what to put into some field you will need to use one of this 2 solutions, text list or taxonomy term reference field.
Technically for both of them you will need to add a new field to your entity content, which means a new table in DB. Thing is that with taxonomy term for each new term in DB entry there will be data written in 3 more tables and one for repeated use of this term. Also for each DB select there will be lookup for data in 2 tables, not one as with text list. So yeah, there is some performance downside to using taxonomy terms. What is good about terms is that you have clear separation of concerns, taxonomy terms are content and with text list you have configuration, so for any new entry to text list, you should do it with code, upstream, deploying it from dev to production. Functionality is almost the same, you can add new, delete unused and change label of both terms and list entries.
There is also a vital part of administration, taxonomies can be administrated on production as it is content, text lists shouldn't be administrated on production, so you have more power and flexibility for your users.
So first instinct could be that maybe you want to use text list to optimize and that is mostly fine, but if you have more experience, you will know that most of the traffic should be served from cache, even varnish, so this optimization doesnt play much here. Also if you plan to have lots of lists, you may think, ok I need lots of filters, so to have a performant "view" you could also opt for text lists, but again with experience you get that you should use SOLR search and facets for this, so again this doesn't play much importance.
So clear winner in my opinion would be taxonomy term, more power, little downsides.