Is normalizing further to index on INT FK rather than VARCHAR worth it?
integer is typically a bit smaller and faster than character types in every respect. The difference mainly depends on the length of the strings.

You asserted that the text data is unchanging, else this would be a strong case for using a surrogate key instead (integer or whatever).

Circumstances that would still make me lean towards an added integer surrogate key:


Strings are much larger than the 4-byte integer. Little to nothing to gain with short strings. The benefit grows with the avg. string length.
The key is used in multiple indexes and/or FK columns, so benefits add up.
You work with a locale other than C (the typical case) and you need rows to sort in immutable (obvious) fashion. The sort order of character types depends on the current locale settings (COLLATION). 
All other tables in your DB work with integer keys and you'd rather not break the pattern.


On the other hand, with Postgres 9.5 or later you can benefit from the "abbreviated keys" feature. But only if you work with locale C on a *nix OS. That would tilt the scales towards using original strings.

Related:


Indexes: integer vs string performance if the number of nodes is the same
Would index lookup be noticeably faster with char vs varchar when all values are 36 chars
Slow query ordering by a column in a joined table
What is the overhead for varchar(n)?