In my experience with Backbone, another relatively small js library, the fact that the library is smaller and "does less for you" also means that you end up in one of these scenarios: you need to figure out how to solve a lot of things that other, larger libraries handle out of the box; or, you need to glue libraries together that provide those solutions; or, you have a bunch of prior experience with the library in question, have solved those problems before, and can bring that expertise (and often that code) to each new project.
These all bring with them their own issues of simplicity (tying libraries together?), maintainability (what happens when I realize my library/framework additions are inadequate, and/or buggy?), and learning curve (instead of learning the API I am learning how to do things with a very minimal API).
To some degree, a small library doesn't solve these problems, it offloads them to you--which isn't necessarily a bad thing. It, like basically everything in software development, is about being aware of the tradeoffs and figuring out the best balance.
But in case of Riot I suppose it's best for you to read the documentation and see whether it does the job for you. I personally think the custom tag approach is a great way to go.
Its the motion of the ocean in the library that matters.