It's my impression that a lot of people are coming from a Angular or Ember-ish background where they're building what amounts to single-page web applications. I'm building multi-page apps that have heavier-lifting back-ends, and React fills the space of building components that can be composed and embedded in the page.
When you're building a single-page app, stores make a great deal of sense. But when you're embadding components in a page, it doesn't make sense to use stores. Not only do I not want to have my components interact, I want to actively avoid having them interact, because that coupling would make the components non-reusable. So tying them to a global state presents serious issues for that model.
It occurs to me that this might account for our difference in perception of the importance of stores.
P.S. It's also worth noting that moving state out of a component and into a store is fairly painless. The reverse is not true; moving state out of a store and into component state is an extremely painful and error-prone process. So it makes sense to start with component state and move things into stores only as needed.
The slider offset is a very transient variable that is not really important. Next time you load an object from the database you'll just convert the value to a slightly different offset and nobody will notice. Are you going to store the offset in the big store?
Redux manages the state of your application as a whole. But individual pieces within the page have no reason to know about the page state. Likewise, there's no reason for your Redux stores to concern themselves with the detailed workings of every component. Why should your app care what's going on inside a button or a menu? That leads to gigantic, overcomplicated states. Let the components manage things for themselves.
A good rule of thumb might be that if three layers of components need to know about a piece of data, it might be good to consider moving it into a store. But if it's only a component and its child components that need to know about it, you're not gaining much by moving it into stores--the stores and actions you'll have to implement are just added complexity. It's incredibly frustrating when I come across code where I have to push data through an action and a store and dispatch when a simple call to setState would have done all the same things faster and with less code.