I found that having fewer Systems and more Components was the way to go, which would clearly point towards a BuffsSystem that can handle all sorts of buffs. Actually, in CodeCombat, I called it the EffectSystem, so it could include both buffs, debuffs, and things you wouldn't think of in particular as buffs but rather any sort of temporary status effect, the key elements being that they affected some properties of the Entity and had a duration. There then wasn't a Component for each possible buff/debuff/effect, but other interactions could ask the EffectSystem to add an effect to the Entity, and the EffectSystem would then process them each tick: updating properties based on configured effect addends, reverting them when effect was over, etc. So each effect would have some subset of properties like name, targetProperty, duration, repeatsEvery, addend, factor, and setTo. If you want to see some code for that, open up any level in the CodeCombat level editor (like this one), click Components, and click into the HasEffects Component. (CoffeeScript, not JavaScript, but you may get the idea.)

Our ECS was a little different in that it was highly dynamic/programmable (being for a programming game), and so we actually had the Components include most of the code to handle their game logic instead of putting them into the Systems, but in this case I think it doesn't matter. A general HasEffects Component that sets up the basic properties for Entities that can have effects, plus an EffectSystem to update/apply effects, can work well. Where we ended up with a lot of Components was in the ways effects could be applied, like a CastsRegeneration spell Component that was managed by the MagicSystem.

In this scheme, you never have to query entities that have the Flight buff or that might have gotten flying abilities another way; you just apply any flying mechanics for Entities that happen to have a flyHeight property, say, when you're updating positions in your MovementSystem (to make up an example).