As I explained a few post above, I like to "import" global variables like that. But not for performance reasons (it will be minor anyway). I do it to have a clean interface between my code and the code "outside". This way you can see exactly what the code depends on by just looking at the initial imports.
It's true that you have to be a bit careful about functions that are likely to be hooked. For those I use an explicit lookup in _G. Again to make it clear that I am accessing code from another place.
I do all of these tricks because I essentially don't like languages with dynamic binding. They are dangerously error-prone. As many errors as possible should be caught at "compile-time" instead of at run-time. When the language does not help me in this respect, I resort to using a strict discipline when coding.
Well, the hooking is much less of an issue since 2.0. Destructive hooking (or any hooking really) of the lower-level functions often leads to tainting the default UI, and breaking things (damn that disappearing pet bar!) I was merely pointing out that sometimes handy side-effect of avoiding later hooks to the function.
local _G = _G creates a direct memory reference to the global environment table, so that you can do _G["some variable"] directly to look up some variable or function globally which is slightly faster than having Lua look up the _G table internally.
Commonly used functions should still be localized individually, but don't overdo it.
Encompass all Lua functions or should the functions be localized individually?
No. The global environment is actually a table as seen there. When you access a global, you're doing a table lookup for it because of this, as well I guess an internal call to the equivalent of getfenv(). So using a local _G is faster (because you no longer need to have getfenv() internally checked), and you can test this in a Lua parser. But you still have to do that table lookup if you use it on your globals, whereas making a local copy makes just that, a local reference to the function's value so no table lookup needs to be done in the future.
The performance benefits of _G or locals are negligible at best, and as Tekkub pointed out to me, each local variable actually takes up the equivalent of a blank table in memory for each function calling it.
Edit: Note that when storing locals of a global function, you're no longer accessing the global of the function but your cached local copy. Because of this, any hook made after the local reference was made won't apply to your local reference. This is important to note if you want a hook-free copy, but generally hooks are made for a purpose after all.