the latter just assures that you get the global version of the function in cases where you might have strfind already defined as a local in a "parent" scope. can't think it'd make any difference in the first few lines of an addon...
personally, i find all of that local = global stuff kind of gratuitous.
To optimize an addon's performance, you want to make access to commonly-used functions "local" access rather than global namespace lookups. This most definitely includes functions like type, next, pairs, select that maybe you didn't even realize were functions.
Some globals you may be okay with being global accesses (or in fact NEED them to because they can be hooked or changed) <snip>
[to still optimize while allowing hooking to work, you can]
Put a "local _G=_G" at the top of the file, and then access them through _G.SomeFunc, etc. This is actually somewhat faster than accessing them directly, believe it or not. (Direct global access involves looking up the global variable table first!)
Edit: Bold section is my paraphrasing for brevity.
local _G = _G
local strfind1 = [COLOR=DarkGreen]_G[/COLOR].strfind -- (1)
local strfind2 = strfind -- (2)
It is faster to access _G.strfind than to access strfind directly, provided _G is already a local. So (1) runs faster than (2) would. Thereafter, either strfind1 or strfind2 would provide equally fast access to the function.