I totally understood the reasoning behind it from the start. Like I said, I use enums a lot too -- as you can see in my UDFs.
I guess what it really boiled down to, for me, is that I'm just not a big fan of the Eval function and I try to avoid it unless absolutely necessary. If you have to use it to reference and de-reference your ini values, it just seems to add unnecessary complexity and obfuscation. If it were me, I would store the integer values in the ini file and use the enums for the setting and testing of the ini values in the script. Storing the values as enums, for my taste, is a bit much. But it is just one old guys opinion.
As for the reasoning as to how it helps you as a solo coder, if you prefer to quickly be able to identify string-based status values (running, stopped, paused. etc.) in your ini file, because you frequently need to read it manually, then why don't store them that way and let the script handle how they are set and tested? That way you can't forget what the values are and can add new values as needed and without having to worry about existing values. In other words, your example my be a better fit for constants instead of enums. If you are storing the values as strings anyway, you might as well store them as they need to be and not have to de-reference them with Eval functions and thereby remove the unnecessary complexity and obfuscation.