Manager that collects and handles multiple tasks that run on events like window.scroll, window.resize etc
Some points.


window is the default object. You don't need to use is. It is highlighted by the fact you don't use it sometimes window.document, or window.TaskManager but then for objects you are unsure of window.addEventListener you add it.
It is not a good idea to stack requestAnimationFrame requests. 


Events related to mouse movements can fire at rates much higher than the display refresh rate of 60fps.
It introduces an up to 16ms delay on the event (and yes users will notice it as a sluggish response). 
If used in conjunction with standard event handlers you will be handling events out of order. 
Completely decouples the handler from the event.

You have decoupled (ignoring above point) the event from the handler because you don't pass on the event object. If you are going to manage events you should pass on the event object so that the handler can access the event.
registerTask will happily push events to the stack without checking if the supplied object is a valid. When you come to handling the event eg processTasksOnScroll it will throw if task.target or task.callback do not result in a function reference. If it throws none of the following events will be handled.
If any of the tasks throws an uncaught error then all following tasks will not be called.


Without knowing more about the project its hard to say more about this approch.

I do feel personally that events should not be one to many. For each event object created there should be one unbroken execution path that completely handles the event. Having events trigger more events is just going to result in an unmanageable mess, as you add code to conditional communicate between handlers wanting priority, or exclusivity.

That is not to say you can not have one handler for many events and then selectively redirect the event to a specific handler.