To add to @daffl's comment...
Inevitably there is always some "lock-in" when you choose a technology and honestly we're trolling Meteor a tiny bit, but I our aim with Feathers is to mitigate lock-in as much as possible by few design choices:
1) What daffl already said about small composable/reusable modules
2) npm module support. You get to leverage all the awesome work others have done (without any additional overhead like porting modules or shimming them).
3) existing Express/Connect middleware just works.
4) a very small codebase over top of another small modular codebase (express, socket.io). The theory being less code, means less to go wrong, which saves devs time writing code and debugging.
Ultimately, you do need to decide whether you want the Meteor sort of approach where it's more of a kitchen sink that gives you all the tools you need but makes it hard to step outside the secure sandbox, or whether you want something that is a bit more flexible. Since, in my experience, all the projects I have worked on inevitably end up with something custom that the framework du jour doesn't handle I prefer more flexibility and small composable modules.
We've tried hard to see if we can strike the balance between offering just enough without getting too much in the way. If you think we're on the right track or not we'd love to hear your feedback.