Another simple benefit to localization is that it can make it easy to fix typos or reword things in your native language, too, if you use short keys in your code and have all real strings in a single place.
Even if you don't plan on localizing, it's a good habit to move all your strings to one place like this, as you can quickly see in one place if all of your strings have consistent tone, style, and word usage.
You're referring to the process of internationalization, which is usually treated as a separate process from localization.
Internationalization is making it possible to swap out language-specific assets at runtime (which is what Lars points to as the difficult part of this which can be carried over to other projects); localization is the process of actually making those language-specific assets. Internationalization is done by spending (usually in-house) programmer time; localization is about throwing money at (usually outsourced) translators.
But what then when you fix a typo in your English text? Or slightly rephrase it without altering the meaning? This means the translation files have to be updated as well.
OTOH, systems where it is very easy to change only the English text without even thinking about the translations have their own pitfalls. Namely that people make "tweaks" and the translations go out of sync.
Even if you don't plan on localizing, it's a good habit to move all your strings to one place like this, as you can quickly see in one place if all of your strings have consistent tone, style, and word usage.