Garbage Collection
If you are doing a few of these then don't worry about it. Any single one of the user cases shown here if used on its own will not negatively affect memory usage.
memory footprint
These will begin to have a potential impact when done in a large loop. Each time a function object is created, it can take up to 754 bytes of memory. If you create many of these, such as 1000, you may briefly hit 1MB of memory depending on the browser which is negligible. 10,000 gets a little worse (~10MB), 100,000 (~100MB) becomes troublesome, and 1,000,000 (~1GB) will probably start to cause some serious issues depending on the client in the form of a minutes worth of UI lock.
scope
The garbage collector will become a factor in the previous situation when the objects are not retained in the current execution context. Each execution context has a lexical and variable environment. The variable environment is the one which will be eligible for garbage collection once the current execution context loses scope. To note though, eligible only means that it will happen sometime and makes no promises as to when.
In order to mitigate growing memory footprint, ensuring that the execution context of the function is implemented to lose scope as quickly as possible will ensure that the garbage collector has the option as quickly as possible to collect. Again, the option to collect may not be realized for some time.
Implementation
What this all plays out to is closing over variables so once their reference is gone, they are eligible for collection at some point in the future when it is convenient for the garbage collector.
performance
In addition to that, the concern to calling the jQuery function should not be significant if used alone. The only time repeating the query becomes an issue is when you have more than roughly 10,000 DOM elements at which point you may already have other problems; and when you are going to iterate thousands of times and want to avoid having the milliseconds pile up. Optimizing anything that takes less than 10 milliseconds total is probably a micro-optimization. 10-100 is discretionary, and more than 100 is definitely warranted.
Furthermore, any time an element is accessed by id, it is directly accessed through a dictionary (hash-table) lookup which is O(1). This means that your DOM will not need to be entirely parsed. However, this may not always be the case so I will assume that we cannot simply stop there.
So if this is only used once, then here is nothing wrong with your first scenario of (there is no need for using the div here, the id is a O(1) lookup).
function showError() { $("#error").show(); }
function hideError() { $("#error").hide(); }
However, if for some reason the string for the id is a class selector and these are being done in large quantity somehow in a loop, you will want to make sure that the function definition is scoped to the loop, and that the element selector is cached (caching does itself introduce an interesting side case where the cached element set may not actually match the page set for things like class selectors in dynamic pages - but that is an edge case).
scope
The parent scope is important because you never really want to be executing code in the global scope. So while these two accomplish the same thing
var divError = $("div#error");
function showError() { divError.show(); }
function hideError() { divError.hide(); }
and
var showError, hideError;
(function() {
var divError = $("div#error");
showError = function() { divError.show(); }
hideError = function() { divError.hide(); }
})();
(note that because the anonymous function in the IIFE has its variable environment referenced by its lexical environment and as a result will not be eligible for garbage collection until that lexical environment is eligible)
They both treat the scope slightly differently. The first will expose the variable divError, while the second does not. In a narrow environment this will not matter as much because collisions in the lexical and variable environments are less likely, but in the global namespace this can be problematic as the lexical environment will not be collected until the entire page is unloaded. This is known as polluting the global namespace.
Alternatives
In the end, this entire analysis comes down to something which should have been rather trivial. If you want to have global access to this element then store it in a safe already in use global variable. Since you are using jQuery, you can simply use the $.
$.errorDiv = $("#error");
and when you want to toggle it, simply use toggle :) Or hide/show if you are uncertain of the state or somehow call it to show twice.
$.errorDiv.toggle();
$.errorDiv.show();
$.errorDiv.hide();
This last section may not apply as directly, I understand, because this was probably a simple reproduction of similar behavior.
