Continuing the discussion from Oplog tailing too far behind not helping:
@workman would you care to elaborate on that? I’d really like to know what I need to look out for when I’m using collection-hooks. Are you completely against it? Do you avoid certain use cases?
Do you simply mean that collection hooks add additional queries to the mongo op log? Thus limiting scalability?
If so, the problem then becomes, what pattern do you then use to replace hooks?
I’m not completely against it, I still use it on collections that don’t have a large number of records. The problem with collection-hooks is the same problem that OPLOG_TOO_FAR_BEHIND fixes, when you do an update, remove, or insert that affects a large number of documents you’ve just queued Meteor to execute N number of functions. Because Node’s single threaded, it locks up the server.
What I did to migrate off was different depending on the case I was trying to solve. In some cases I changed what I was doing to a Meteor.method and for a few cases I added a separate node process that listens to the oplog.
I’ve noticed some problems using collection hooks, but I tend to only use them in intensive “setup” styles
This sounds more like application design consideration rather than a problem that the package introduces.
To answer the original question: of course there are implications. Some good, some bad. It depends on how you design your application. 
A better question might be: would your users rather wait an extra 200 or 500ms (or more) when they’re fetching a record or when they’re updating a record?
The real win with collection-hooks is being able to offload milliseconds from a fetch/find to an insert or update. Doing so begins by identifying any joins in your publications and find/findOne() queries and flattening them into a denormalized master-detail pattern. Once that’s done, the code to calculate the join in the find/findOne() can then be moved into a collection.after.insert() or collection.after.update() hook. Thereby effectively pre-optimizing your database queries by moving milliseconds from your read operations to your write operations.
Not every application will work with this approach; but, by and large, I think it’s safe to say that most users will be a bit more patient with a big ‘please wait…’ message after they’ve pressed ‘save’ or ‘submit’ than while they’re just browsing data and searching for something.
You always have to pay the tax man; but sometimes it’s possible to adjust when you pay. TANSTAAFL.
Alright, so my perception of the original post was that collection-hooks is something to be avoided.
Your take reads to me more like “it is a tool that’s invaluable if you are careful with your application design”. That’s perpahs what I’ve been doing with collection-hooks in such clever ways and I do find it an invaluable asset in my arsenal of packages.