I'm the project lead for Aurelia, so I'd like to take a minute to address a few of the points from the linked post. Jeff makes some valid points, for sure. However, there is also some inaccurate information and a healthy dose of subjectivity.

* Documentation - This one tends to be highly subjective. One's happiness with documentation is often highly dependent on learning style and what you are trying to do "in the moment". Jeff describes it as a "mixed bag". However, we've had plenty of people praise Aurelia's docs as amazing or even make statements such as "this is the way all documentation should be." Do we have room for improvement? Absolutely. In fact, we're working on a completely new documentation site right now.
* TypeScript Support - We have a huge community of TypeScript developers who are quite happy with our support for the language. We provide d.ts files for everything. We also have a number of our libraries that are now completely written in TypeScript. This includes our new Webpack tooling, our Validation library, our UX Component library and more. We've actually worked directly with the TypeScript team to provide scenarios for them, which resulted in new features for TypeScript and submissions to ECMA for future versions of JavaScript.
* Build System - Aurelia supports multiple options, including RequireJS, SystemJS, Dojo and Webpack. We have a very diversified community. Our CLI is designed for beginners who either are completely new to SPA frameworks or don't know how to use tools like Webpack. It's designed to get them up and running quickly and easily. It has been exteremely successful in that area and we've received a ton of praise for it. If you are a Webpack developer, I would expect you to use a Webpack setup instead though. We have a Skeleton for Webpack that's based on Webpack 1.x. However, we've got a completely new set of Webpack 2.x tooling. There have been blog posts about it, there's documentation, dedicated plugins, etc. It sounds like Jeff missed this somehow. Lots of people are using it though and loving it. We're doing some work now to broaden the availability of our new Webpack setup, so hopefully future devs won't have the same discovery problem that Jeff did.
* Dependency Injection - This one is is pretty accurate. Our DI is extremely powerful and extensible, but we try to stay out of your way as much as possible. You can even use DI without decorators at all, in a pure ES2015 fashion, if you like.
* Component Encapsulation - Here Jeff doesn't talk about the component model at all really. He's fixated on whether or not you can put a component in one file, something that tends to be a subjective requirement. That would be fine but he missed the point that you can include your JS and HTML in the same file with Aurelia as well, by using our @inlineView decorator. We've supported this for two years, but maybe we need to talk about it more. That said, we generally don't recommend this as the default practice, because we hold the opinion that it's better for developer/designer collaboration, parallel work, and sometimes even source control, if you put these things in seperate files. If you want to do it, you can though. The Aurelia strategy is to have a lite set of opinions but to always enable developers, which is why we support both paths. One other quick point here: Jeff calls out our component naming as "magic". However, our documentation very clearly points out that, if you don't provide an explicit component name, the convention is to use the export name. This is a fundamental convention in Aurelia that is well-documented.
* Routing and Fetching - Here Jeff has a couple of questions about getting access to parameters in sub components and altering the way that routes generate titles. Those are all possible and would have been a good opportunity for Jeff to engage with our very helpful community. Jeff makes one cricirtism that is very valid though. Our documentation on routing is lacking in some big areas. I don't think there's any doubt about that. It's something we're working to remedy. Perhaps this is the central reason why he thinks Aurelia's docs are a "mixed bag"?
* Ecosystem - This point really frustrated me. Our community is not tiny. There are tens of thousands of companies using Aurelia all over the world. There are tons of very large, well-known brands using Aurelia. Unfortunately, we can't share these names all the time. Please understand that Google and Facebook have considerable influence over other companies that we do not have. For example, if company X uses Angular or React, they want Google/Facebook to publish that information because the Google/Facebook brand is likely bigger than theirs and they want to ride on the coat tails of the larger, more influencial company. In our case, Aurelia as a project, is almost always smaller than the dozens of Fortunate 500 companies that are using it. So, they don't have any motiviation to share that information. Because the bureaucratic legal and marketing hoops are so numerous, we end up not being able to share many things publicly.
* Ecosystem Part 2 - We have tons of 3rd party modules for Aurelia. Jeff states that there are no third-party component libraries for Aurelia. That's not correct. We've had public announcements about Telerik and Syncfusion component libraries. There's also a Materialize component library and at least one very large community-based component library in addition to the collection of individual components that people have built. Aurelia itself has an official component library. It's early, for that library, true. One thing I take away from this is that we need to focus on and "highlight" even more in our official docs and site these 3rd party components, because maybe people just don't know that they exist.

Now, we realize that Aurelia is far from perfect and that we always have plenty of work to do and things to improve on. I and my team of about 30 engineers have poured countless hours, worth millions of engineering dollars into Aurelia. We don't have the brand power of Google or Facebook. Who does? So, if you write this type of comparison post, please be careful to validate the information and maybe even reach out to the project contributors for feedback. Posts like this can cast all our work in an overly-negative light, particularly for those who haven't encountered Aurelia before and don't know better. We're all working for the same thing here and want to help each other and our businesses succeed. I always take feedback like this to heart and I and my team will continue to work hard to make Aurelia better every day. We invite everyone to join our community and contribute together to making Aurelia the best platform for modern web apps.