I would say that the feature set is pretty powerful as is, and it shows in the earlier history (having worked with Mixins since before it was called Mixins). The history reaches further back than the first commit to having been developed for Mumfrey's own modloader (LiteLoader).
As someone else already replied, Mumfrey still practices private development and only pushes new code after his own extensive testing. He has long periods of "public" inactivity because code refactors and other changes can be delicate given the widespread usage of the library within the Minecraft modding ecosystem, and as such, he doesn't want the distraction that in-development can attract from said community.
There's a fair bit more that is possible that would otherwise require a fair bit more code wrangling with AspectJ or BytecodeBuddy to achieve the same effects.
The applications for Mixin wasn't to mock a method or two, it's to enable full-scale modification of an existing Java application at runtime without recompiling/redistributing the original application. In the case of its origins, modifying Minecraft server to add a non-obfuscated API and implement said API on top of it through Mixins. The way this is achieved is practically at the class load point in time so the runtime costs are reduced to maybe a couple of seconds (as of current writing, Sponge has somewhere around 1.2k mixins overall). Could there be a better native API? I'm hoping so, Java's Class File API (JEP-484) is a pretty good start, but I don't think it's quite enough yet to enable the full functionality of what Mixin does.
It's unfortunate the thread was locked, I feel like it's an important topic to discuss. I only hope the official announcement thread stays open for discussion.
To be honest, a lot of demo ware is used rarely just to test functionality, then left to rot in the old file system, sometimes uninstalled entirely and never thought of again.
It would make sense if it was 30 uses, instead of 30 days, but with the same token, the frequency of use is often the telling sign of whether the software is worth purchasing or not.
As someone else already replied, Mumfrey still practices private development and only pushes new code after his own extensive testing. He has long periods of "public" inactivity because code refactors and other changes can be delicate given the widespread usage of the library within the Minecraft modding ecosystem, and as such, he doesn't want the distraction that in-development can attract from said community.
reply