The Store interface in the post assumes a single thing is created. If requirements change and you need to create thousands, the naive change will end up calling Store(Widget) that many times and thus that many SQL queries.
Abstractions are useful, but they also leak. The wrong abstraction can make many useful things impossible.
If you use Store interfaces that are specific to the needs of the client, rather than building one universal Store that covers every possible use case, isn't it fairly easy to modify that abstraction when the need arises? (Sort of the same idea as "backend for frontend" compared to a completely general backend API.)
Those needs will change. Requirements will come that are easy to implement efficiently in terms of SQL queries, but impossible through the abstraction. You may then be able to come up with a new interface, which requires you to change your existing code.
Just like ORMs, such interfaces can be useful, but have the cost of limiting your options.
I'm not sure how I feel about it yet, but I've seen codebases that have tests asserting the number of queries that should have been run. Those tests have caught a couple of issues in the past, and they do seem to make the engineers on that team understand better what their ORM is doing.