Since 2015, I am using Aurelia. That means that I have experienced the initial hardship of no documentation (with the nice documentation, I am slightly disappointed as it halted the upvote for this answer on SO ), and transition through JSPM + RequireJS/SystemJS towards Webpack. Even though there were some pretty appealing features.

First and foremost, coming from the .NET development background, I absolutely loved the fact that I get to use TypeScript from start. It gave familiarity. Aurelia looked also familiar because of the non-intrusive lifecycle hooks, and use of DI. In my head I was “This is just like the ASP.NET pipeline”. I appreciate that it pushed me to stay close to the standards. Just write your TypeScript class, have a HTML for that, and Aurelia turns that to a component/view. You want more controls, use life cycle hooks in your VM, or sprinkle some bindings in the HTML (w/o making the markup alien). Above all, till this day I am a fan of the elegant API designs from Aurelia.

Then comes the EventAggregator and dynamic composition. You need to understand that only event I was aware of then in HTML+JS world is the UI event, originating from HTML elements. To have a way to generate custom events, and to create pub/sub model was just awesome. And we loved the dynamic composition so much, we created a dynamic view generator for CRUD apps. That was our Batman moment

Last year, we started a new project. Though I was all for Aurelia, our team decided to go through a round of prototyping with other frameworks, and for good reasons. React, and Vue had the initial disadvantage of mixing JS and HTML together and our team is not a fan of that. With Angular, I never saw an example that has not used CLI. To me it hinted that the framework is created be so complex, and the dependencies are so oddly spread, that simple handmade (w/o CLI) component has the potential to go horribly wrong (but again I was not that much into Angular).

However, what made us choose Aurelia again is 2 folded. First, it is far easy to create aurelia plugins as npm packages, and use that with main app. This ensured modularity, and increased code reusability. This was of utmost importance for our team, as the App was going to be a giant. Therefore, to keep everything in one package was out of question. Secondly, the I18N support. Aurelia let us change the language on the fly, where Angular told us to create an instance of the app for every language (not sure if that has changed now) ?? As we started early with Aurelia, our company ended up creating several gulp packages to build the toolchain (extraction of text, compiling those etc.) for I18N (however, those have no strict dependency on Aurelia, I think). I never cared before about the potential of these 2 apparently humble features.

At this point I realize that I have not said a word about the day-to-day stuffs Well, as a day-to-day activity, Aurelia perfectly fits my/our teams design principles, and the requirements of the apps we build.