Pros and cons of different ways of storing Enum values in the database

Uh varchar is 1 byte per "symbol" nvarchar is 2 bytes per "symbol" an int will be larger than a 3 character varchar. Mixing up bits and bytes is not a good sign.

Usually, enums are not having big lists of keys. The biggest enum I've ever seen was 300 key in it. which is only 3 symbols. I have rarely met enum names with 3 or fewer symbols.

If its an int then its 4 bytes not 3 "symbols", if your storing string your using the name not index. Seems like a point is trying to be made about 4 bytes int vs 3 byte varchar names but instead mixing int string size.

When you are storing enums as a string you are not depend on the order of enums in code, so you can easily reorder them without any side affects. To avoid this you can implicitly specify integer values for enums

The opposite is also true when storing names instead of ints you can refactor the name without changing the data. What do you do more often change enum order or name?

Not a big fan of using enums anyway, I prefer some sort of coded value where you store a short string code in the db that is human readable with a longer description the users see, that way the description can be reworded if necessary, you can also tack other metadata on to the code if necessary. Many times the coded value is in the db as a table or even one table per coded value with foreign keys so it can be modified and joined. Not as simple but more flexible IMO.