How is it that setTimeout()'s delay timer executes ("counts down") immediately even while the main thread is still running (has not completed the call stack)?

There's no code sitting there decrementing a counter. The implementation is allowed to vary between environments (since setTimeout is provided by the environment, it's not part of JavaScript), but here's a likely one: Since the main thread services a job queue, an implementation could look at the list of timers prior to pulling the next job from the queue and, if it's time for a timer to finish, add a job to the queue to call its callback. Then it processes that call in order from the queue when it comes up.

When programmers talk of "Asynchronicity" in Javascript, are they talking about the ability to execute some code in parallel with the main thread (like how the delay portion of setTimeout works), OR are they talking about the ability to simply postpone a function from executing until the main thread's function stack has emptied

Probably both and more, but also less. The point of flagging up that something is asynchronous is to say "you won't see any result for this until the current task completes" (since no asynchronous callback can occur until the task completes). Why is usually clear from context: Because we have to wait for a network resource to arrive; because we have to wait for the user to click something; because we have to wait until the browser is about to render the next frame; because we have to wait for a timer to fire; because... You get the idea. :-)