I'm not familiar with how construct resolves variables, as I haven't worked directly on that code, but language design and compilers are a bit of a hobby of mine so I can probably cast some light on it. I will say the performance cost is probably negligible, it's rarely an optimisation that is worth thinking about in most languages as well laid out code tends towards the more optimal version anyway.
Short answer: it will either have no difference, or it will be faster the closer the variable is to the current scope.
Long answer: Event sheets are basically interpreted like a scripting language. They have some rather unique specialisations and optimisations, but for this example we can consider them the same. Resolution of variables in an interpreter typically involves walking from the current scope to the top scope while searching for a matching variable name. The closer to the current scope it is the less scopes need to be checked and the less work needs to be done. However, it's more common for an interpreter to resolve the location of a variable before beginning code execution and store it for later. So instead of searching for the scope which contains the var on each get/set it know which scope contains it, and hence can modify it straight away. In that situation there is basically no performance difference between scope levels.