1) It is purely a notational convenience. It makes absolutely no difference in the final compiled script.
2) Accessing a property in another script is bound to be less efficient. One of the most efficient ways to achieve what you are doing would be this:
pLevel = (Game.GetForm(0x14) as Actor).GetLevel()
especially when used on a single occasion. It is fast(*, and it requires no overhead for the property structure in terms of memory used. Still, accessing the player reference value from a variable without any function calls whatsoever is even faster, so if you use it multiple times, it is most efficient to first have it in a variable, either through a property definition or by storing the value given by Game.GetForm(0x14). Note, that GetForm() returns a 'Form' value. Depending on what you use it for, you may be able to use it directly, or you may need to include "as ObjectReference" or "as Actor" based on what the native parameter type is for the function you will be calling on it. If there is a type mismatch, sometimes the compiler may approve but just insert an additional type recast of its own, which would be needless if you can get it right yourself.
*) GetForm() is one of the few undelayed functions, that is processed immediately. In comparison, GetPlayer(), like most functions, is delayed, and it causes the script to pause until the next frame, when it will provide its return value. In this case, GetLevel() will cause just this kind of delay, so it makes practically no real difference to overall speed, whether you feed it from a property, or some other variable, or GetForm() (or even a property from another script, I would think but am not sure, as long as that property is of the auto type). The small speed differences these approaches have in getting the player reference value may make a difference, if the script engine is overburdened and struggling to process everything required during its allocated time window per frame, but not otherwise.