Feathers is a really excellent back end platform.  It checks a lot of boxes for me and I would like to explain some of it's virtues.  I prefer to invest my limited learning cycles into technologies that show clear longevity and ease that also provide me with measurable competitive edges.

It's been around a long time, about 5 years, and while it is not extensively popular it has accumulated a solid support basis from the community including devs and funding.  It is a quite stable and actively supported and developed system that isn't likely to disappear or change radically on me (or you) in the next few years.  In an environment where community projects come in a matter of years to sometimes only months, this is important.  

At it's core, feathers is actually an abstraction for the traditional web transportation layers.  Which means that a feathers back end can communicate with a feathers front end with a number of intermediary transport layers.  Socket.io, REST, and GraphQL are supported.  I could use one of the transport layers directly, or write my data queries in feathers itself and get additional advantages.  If or when a new transport layer appears on the market, like say the slowly growing HTTP2 adoption or a superior implementation of a bi-direction communication package like socket.io appears - I won't need to change any of my business code to take advantage of it.  A feathers update and turning on the feature and I'll have the advantages available from it.

The main feature I was looking for when I found the system is reactive data for clients like meteor and firebase provide.  A real-time API.  This is where back end updates are pushed to the client as they occur.  Which is an excellent feature that I have always been a fan of, especially when using a system that largely does that work for you.  Because it's not easy to do if your underlying technology choices do not support it and you have to build it yourself.  Traditional REST and GraphQL implementations that I have used and helped to build generally do not.

Feathers is not opinionated as to which type of database you use.   It has a solid stock of default database adapters including in memory, localstorage, file system, mongodb, SQL, and elasticsearch.  It's flexibility has been a boon to the number of projects which I have found it suitable for, and I find myself using a variety of the adapters depending on which one is most advantageous.  I've had some small projects that I've built for embedded systems where having a database dependency is extremely painful.   I can instead just use the best combination of in memory and file system and have a clean implementation that retains the necessary data while minimizing flash wear with a minimum of complexity, memory consumption, and no external dependencies.  

Feathers comes with an authentication system.  Which you can use instead of writing your own, and it's generally not a good idea to write your own.  Or you can plug into one of several existing auth systems.  

Feathers provides a CRUD and query operation suite that's useful for getting running quickly similar to a system like loopback that helps you get an API off the ground.  The hooks into that system allow you to build out permissions or perform necessary modifications to the data while it is in flight to or from the database.

Feathers is a simple system that provides this core feature set and then gets out of your way.  This simplicity makes it reasonably easy to pick up and learn as well and is good at not getting in your way.  I highly recommend it as a tech to pick up and learn in a small project to put another tool in your tool bag.