Interesting approach, it sounds very like the approach used to generate resources for this website. I wouldn't shy away from calling it a framework, or from rewriting some libraries yourself. The downside with an agglomeration of libs/packages is that they gradually drift out of sync with each other and require vigilant updates, the upside is of course that you don't have to maintain them. There is some value I think in having examples of how to put all this together, and being able to quickly add new resources to your sites with templates.
I would avoid the npm dependency and other libs like jquery - no need for that really. Also consider generating new resources using templates with something similar to the rails command - this is something I think rails got right.
Re incrementing ids being a security risk, I'm not sure I agree - perhaps in certain circumstances, but in most cases, the authorisation for a resource is the important restriction, the identifier for the resource is arbitrary and doesn't really matter. It's only if you have sloppy authorisation that a user can then exploit incrementing ids to walk the space of resources and access them, and typically identifiers and urls are not well protected, so your url with your obscure id is just as likely to be found in email or shared and then exploited than one with an incremental id. The moonpig bug linked is an example of this - they had no authorisation in place, so random keys wouldn't have helped them, just made it harder to exploit.