Part of your question is TK specific but I’m going to try and respond from a more general Shotgun perspective.
Definitely there is value in doing the above. The underlying database has a limited number of fields it can support per entity (between 250 and 1600 based on datatypes) so removing and cleaning up redundancies is a good thing. Performance-wise, that’s potentially a smaller amount of data to search through and index as well as a smaller schema for your site, all good things.
It will cause a hit in performance but the impact depends on which fields you are returning.
Regardless of the field type, more fields mean more data to serialize and send over the wire but this impact, although certainly not 0, may be negligible. If the extra fields are simple data types like numbers, text, list fields, checkboxes, etc., their impact beyond serialization and transfer time should again be negligible.
You’ll get a much more noticeable performance impact as you start asking that entity and multi-entity fields be returned. These field types require that extra database joins or extra database queries be performed for your single API query. The same is true of thumbnail and query fields. Depending on your scale of data and field configurations this impact will vary but can start to be noticeable.
These are of course broad guidelines and generalizations. The actual impact is very dependant on your query, fields returned, your schema and your actual data. Nothing beats a little performance testing with some simple scripts and API queries against your site to truly understand the scale of any impact.
I sure hope this helps you out.