Suppose you have a translated application that uses a locale key-to-text mapping.
It's tempting to structure your keys so that you can reuse them in places that require the same text. The obvious benefit is that you spare some lines, and allegedly provide a more consistent language interface.
However, let's look at some drawbacks:
You only allegedly provide a consistent interface, because in order to do that it means that every time you want to say something in a page, you're supposed to go over the whole locale file and see if there's already something that fits you there. As the application grows, this takes longer and longer. Add to that the fact that one day you might change that translation in order to tweak a certain page's communication, and have it wrongfully affect several other pages, that have nothing to do with that change.
If your locale file isn't structured by pages (as in, a page, and all text keys that are used in it), then it gets harder to look at the locale file and know what is used where. This is extremely important for both developers and translators. For developers, because they need a quick way of knowing where to insert a new key, and not start thinking about it; for translators, because they need to know what's used where, as they work on their translation.
Now let's consider some tips:
It may be useful to add a "shared" subtree, just for those things that really need that reuse. So in other words, there's no reuse by default, but it's possible if you need it, where it could actually help you.
If you need to edit your locale file and change some things which are repeated several times, then either just take the time and work on it manually (hey, at least it's O(n)), or write a script to do it for you. Whatever you estimate to save more time.