Some things vary between locales, but should not always be localized. One example of poor localization is the OmniOutliner application. This allows you to select a type for a column, and one of the types is currency. This uses the currency symbol for the current locale. If you produce an outline of costs in the UK, this will be pounds sterling. If you then send it to colleagues in Japan and the USA, they will see it in Yen and US Dollars respectively. The amounts will be two orders of magnitude away from the ones that the original author created. If you send it to someone in Zimbabwe, it will be even worse.
The calendar example from earlier is another case where selecting the current locale is far from ideal. It prevents the user from easily setting a meeting in a different time zone, which makes iCal a problematic application for anyone who travels on business.
These are two very different cases. The first would be solved by allowing the user to select a currency, rather than only permitting the current one, and then using NSLocale to get the default presentation attributes for that currency.
The second one is addressed by presenting the data in the current locale, but allowing a different one to be specified when entering it. If you have a conference call scheduled with someone in a different time zone, they will often give you the time in their time zone. A calendar application should let you enter this time complete with the time zone, but then display it in your time zone. iCal almost gets this right. It separates the storage and display formats, storing the data in a time-zone agnostic way and only using the locale information for display, but it fails by assuming that the user's current locale is the only useful input format. Specifying other display formats would also be useful for iCal. If you're going to be in a different country between certain dates, then it would be useful to be able to specify a different time zone for displaying events on those dates.
When it comes to localization, it is important to think about use cases before blindly applying the techniques in this article.