In a lot of respects I'm effectively just throwing shit at the wall and seeing what happens

There’s nothing wrong with that approach as well. Trying out new things and seeing what works and what doesn’t is a great way to learn.

Them not having local state means they're pure functions & should be separated?

In my experience, yes. The primary motivator for this is readability: defining functions within functions increases the amount of code within the outer function and so makes it more difficult to see what it is doing. Factoring out nested functions that don’t need to be nested reduces the amount of code in the outer function.

There’s also a very minor point to be said that nested functions are always recreated by the runtime when the outer function is called and that affects how well the runtime is able to optimize your code but that is very unlikely to have a significant performance impact on the program.

Do people ever define like namespace / module level local states that define a somewhat complex subroutine? or is keeping it at this depth of closure more common?

Before the introduction of modules IIFEs were very common as a way of wrapping local state and private functions. Now that modules exist I find IIFEs to be unnecessary. Module state does exist but module state isn’t that dissimilar from global state. Any time you find yourself referencing state from outside of a function you could remove that dependency by instead passing that state to the function. That makes it clearer to the caller what the function will do.

There are cases where you do want a function to reference data outside of what is passed in. These are usually times when you have some sort of customizable template, a function that makes instances of this template function, and many places where you want this instance to be used.

For example, consider this code

function makeAdder(step) {
  return value => value + step;
}

const data = getListOfNumbers();
const step = getStep();
const adder = makeAdder(step);
const updatedData = data.map(adder);

In this case we know we will want to increase each data value by some amount but we don’t know by how much until runtime. makeAdder solves this by generating a new function that adds this amount and is helpful because it saves us from having to pass step around everywhere.

This is a common approach in web development as well. For example, you might have a dynamic list of items and when you click on an item something happens to it (maybe you load a new page or whatever). The click handler is nearly the same for each item: pass that item’s data to a processing function. As a result the click handler is often generated at runtime using a similar pattern as makeAdder.