Yeah, the storeId doesn't really matter unless you reference it explicitly.
The point is that the storeId on the class is used as a fallback if none is provided in the constructor call. As you can practically have multiple stores with the same storeId (though it's most likely a very bad idea), the storeId does not seem to be *really* really required by ExtJS.
Currently what SA does when you pick a store for a view is that it will output whatever the store's storeId is in the generated code. It would be helpful if there was a way to specify it should automatically create a new instance of the class instead (ideally with an auto-generated random storeId).
One problem remaining with that approach is that paging toolbars need an explicit store instead of inheriting the store of their container. This is most likely a shortcoming of ExtJS rather than SA, though.
Right now, it's impossible to create views in ExtJS that have stores in them and then create multiple instances with different stores without overriding the store property in the constructor (i.e. it's impossible when this is not an option, such as on a grid nested inside a view you want to instantiate on the fly). The only way around this is overriding Ext.define and Ext.applyIf.