This is a well written case for your architecture choice. I think it's a reasonable option especially if you like to think of your components as places that house business logic.

To offer an alternative point of view:

I personally find it very useful to think of my components as nothing more than visual representations of state. If the scope of their responsibility is to represent the current state, and to dispatch events on user input. This makes it really easy to refactor components because they contain no business logic at all - only presentation logic. This makes testing the components very simple as there are no internals to test or mock. I can seed a state I want to test for and make sure the component renders what I want.

The store then becomes the place where all the business logic (and none of the visualisation logic) lives. When I'm testing this business logic I do not need to worry about the component or visualisation at all. I just need to test that the getters, mutations and actions do what I expect.

I find this separation easier to manage and test.

YMMV (and obviously does) and it may be because I came from primarily backend where the delineation of views and logic is more natural and explicit