If one thinks of them as proxies to the closed-over objects, they are quite like "procedures". Another way to think about them is simply as objects with only a single method.
Also, they can still be "pure functions". Purity is a relation of side effects, not of mechanisms. (Even then, it's a somewhat loose definition -- is allocating memory a side effect?) If you don't allow closures to escape their declared scope, you can handle closed values as extra parameters. So closures don't mean you suddenly can't write pure functions, it means that some input to the function is pre-determined. In other words, closures have the same implications to purity as parameter binding -- absolutely none.
> Even then, it's a somewhat loose definition -- is allocating memory a side effect?
This is leading nowhere. Is loading a value into a register a side effect? If you care.
No, that's what objects give you. Classes are merely one means of creating objects (others exist), but the benefits come from the objects, not their means of construction.
But closures do. And thus, why closures are a poor man's objects, and objects are a poor man's closures. As an example, Java closures are really anonymous objects with the closed state as instance variables.
> More importantly you could have multiple instances of that shard state without explicit management, saving a lot of complexity and effort.
Technically that's what classes gives you, not objects. But agreed on the sentiment.