Have not used it myself, but having a quick look at it I don’t think I likely ever will. Mostly for personal preferences with the projects goals and design than anything else.

I don’t like large do everything frameworks. They are ok when you want to do what they were designed for. But as soon as you step outside that they become a nightmare to deal with. They also tend to grow more complex over time as more of what everyone wants gets added to them. A framework author’s case against frameworks is a great talk on the matter. Instead I prefer simpler smaller focused libraries that I can pick and choose from that best suit the application I want to build.

Also it seems like the MVC pattern, which I dislike. Personally I like to group code that changes together next to each other. Where as MVC groups code that has the same function together and splits up code that tends to change together. This means for any change or feature you are editing many files across many folders which gets tedious rather than just co-locating all the related code in one directory or file.

Because they include all dependencies for everything you might want they often lag behind upstream projects. This was a huge issue for me years ago when I tried out the Rocket framework. I wanted to use a hosted postgres DB that only supported https connections but the version of the library it was using did not yet include that feature - basically killing the project there.

They can be great if they do everything you want in the way you want and loco looks to be well built and maintained overall. But I find far too often that they don’t, if not at the start of a project then eventually as my projects evolve (which is far worst). I would also question its staying power though (we have seen popular and promising frameworks before that suddenly stop development) but only time will answer that.