In developing the next major version of our major product line, I made sure we re-visited every aspect of the application. In a sense, the existing team had to make a valid argument for every feature to be included in the product. One aspect that was not previously considered was internationalisation. Being able to localise your strings to "foreign" languages and format your numbers to an international audience is a key benefit and opens our product up to a massive user-base in the future. Aside from the obvious features that .NET localisation offers, such as multi-lingual and culture-specific formatting, working through your product and using localisation features offers many other benefits which are useful even if you want to stick to "International English".
Reduce language clutter - by focussing on identifying the labels to apply to controls, you minimise your language clutter. When talking about writing files to disk, a Save Filename label could appear as "Save File as:", "Save Filename:", Save as:" or even "Save FileName". This provides an extra level of discipline to ensure terms of reference are consistent, particularly across a team of developers.
DRY (Don't Repeat Yourself) Principle - If a section of code ends up being "duplicated", we extract it into a searate function according to the DRY principle, but this can also apply to text. By re-using your term definitions you make updating your terms simpler. An example is when working around a particular product feature which ma be codenamed while in development, but will be rebranded when Marketing decide how to push the feature to the user-audience. Re-branding across the site in this way becomes much easier than a Search/Replace. This is also very useful for spelling mistakes!
Reduce security threats - Using the asp:Localize control in ASP.NET to display the localised text can provide an additional layer of security protection by using the Mode="Encode" attribute, which reduces the risk of script injection and therefore, cross-site scripting attacks for a site. Even if not referencing a localised term, the asp:Localise control is a must for displaying content from the user or the database. Make it discipline and you can delegate your protection of script injection - to a point.
Lower the technical barrier - by franchising out your strings to what is essentially a text file, you can have your Marketing team or translators modify the file. This is known, but it also allows you to modify the file seperately from the code itself, while potentially keeping the file within source control.
These are all pretty obvious when you think about it, so much so that I'll probably work towards localising all my applications in the future. For the sake of a slight change in how you do things, it's worth the effort in consistency, maintainability and safety.