What you're doing here is utilizing closures.

function toggleExampleOne(){
    button1.classList.toggle("activated");
}//END toggleExampleOne

This is closing over the variable button1 in the outer scope. This will cause the function to be evaluated with this context every time it is called, which can be inefficient. There's a process you can do called lifting which flattens the closure - this is what your example three does.

However, I would largely not be too concerned about inefficiencies here. Micro-optimizations can quickly consume you: do what works best for making a maintainable application, then if you have performance problems, measure, and optimize your hot paths (the parts of your application that are used the most often). Especially so since most javascript engines are really quite optimized and will know how to transform your code in subtle ways to improve performance (like doing that lifting for you).

If you're worrying about cluttering up your global namespace though, look into modules or namespaces.

The concept underlying your question is so important I feel it needs another answer rather than just a comment (as I had started to do).

The other 3 answers thus far provide some useful points of consideration on whether a given situation merits using what you call "nested function calls". But perhaps a more important point is hidden in the comments under your question: in case you missed the subtlety in what those erudite folks are suggesting, Carl, you have discovered for yourself the topic actually called functional programming. If you have never seen the term, you might not have thought it was really a "thing" in @HighPerformanceMark's comment.

But indeed it is! Functional programming has been written about for decades, since John Hughes' seminal paper Why Functional Programming Matters. There are some languages that are functional languages (i.e. they only let you write in a functional programming style), languages like Erlang, Lisp, OCaml, or Haskell. But there are many more languages that are hybrid imperative/functional languages. That is, they are traditionally imperative languages but offer some support for functional programming as well, including Perl, C++, Java, C#, and many more. Wikipedia's entry on functional programming provides a nice section showing a comparison of functional style vs. imperative style for a number of languages.

There is much to say on the differences between imperative and functional styles, but the key starting point is that with functional programming, functions or methods have no side effects, making it in general easier to both understand and debug programs.

For further reading, you might also take a look at Reginald Braithwaite's Why "Why Functional Programming Matters" Matters and another interesting post here on SO, Why functional languages?

Nested functions have access to their parent scope so you could change state in a parent's scope from a deeply nested function. For example

function one() {
  var a = 1;
  two(); // a = 4

  function two() {  
    var b = 2;
    three(); // b = 4

    function three() {
      var c = 3;
      four(); // c = 4

      function four() {
        a = 4;
        b = 4;
        c = 4;
      }
    }  
  }
}

On one hand this is pretty powerful. On the other hand it can easily get sloppy and hard to reason about because you have to make sure any child function hasn't changed a value in any of its parents.

If you stick to not nesting your functions you won't have to worry that the state inside your function is being changed from inside of a nested function.

function one() {
  var a = 1;
  two(); // a = 1
}

function two() {  
  var b = 2;
  three(); // b = 2
}

function three() {
  var c = 3;
  four(); // c = 3
}  

function four() {
  a = 4;
  b = 4;
  c = 4;
}

Nested functions have access to their parent scope so you could change state in a parent's scope from a deeply nested function. For example

function one() {
  var a = 1;
  two(); // a = 4

  function two() {  
    var b = 2;
    three(); // b = 4

    function three() {
      var c = 3;
      four(); // c = 4

      function four() {
        a = 4;
        b = 4;
        c = 4;
      }
    }  
  }
}

On one hand this is pretty powerful. On the other hand it can easily get sloppy and hard to reason about because you have to make sure any child function hasn't changed a value in any of its parents.

If you stick to not nesting your functions you won't have to worry that the state inside your function is being changed from inside of a nested function.

function one() {
  var a = 1;
  two(); // a = 1
}

function two() {  
  var b = 2;
  three(); // b = 2
}

function three() {
  var c = 3;
  four(); // c = 3
}  

function four() {
  a = 4;
  b = 4;
  c = 4;
}

I use a nested function to find matches from a list:

def get_exact(data, key, match):
    def is_match(item):
        if (key in item) and (item[key].lower() == match.lower()):
            return item
        return False
    return [i for i in data if is_match(i)]

No other calls in the project have a need to use is_match(item), so why declare it separately?

However, I will say that, for my example, declaring is_match() outside of get_exact() does run around ~0.04 seconds faster in 10,000 iterations.

def is_match(item, key, match):
    if (key in item) and (item[key].lower() == match.lower()):
        return item
    return False

def get_exact(data, key, match):
    return [i for i in data if is_match(i, key, match)]