'Fast' is a poor descriptive choice for a library that was clearly written without attention paid to CPU performance characteristics, GPU performance characteristics, or the nature of modern Canvas implementations.
EDIT: A quick glance at the sample game 'O!' in the chrome profiler shows that it is triggering a garbage collection roughly every second. Pretty bad for a game with such low scene complexity and rendering complexity, and those pauses may be long on a mobile device.
Based on a casual review of the source code (which I'll note is quite readable - good job!), here are some obvious problems that probably need to be addressed, both in terms of actual performance and code quality.
Don't render the scene in graph traversal order; doing so ensures that the number of graphics state changes (shader, transform, texture, etc) is as high as possible. Most game engines render using a more sophisticated algorithm where your drawing operations are ordered (as possible - obviously layering has to be preserved) by graphics state in order to minimize overhead.
For some documentation on this approach, see articles like
http://realtimecollisiondetection.net/blog/?p=86
I've been using this approach in my games for years and it produces a huge measurable performance improvement on virtually all modern architectures (even canvas, though it's less significant there)
The tickBefore/tick/tickAfter architecture is particularly suspicious, as is its use of poorly-scaling algorithms/primitives like Array.splice. Usually this sort of thing is more clearly and efficiently handled by having an ordered set of operations (typically represented by a linked list, a heapqueue, or an array of priority-value tuples that you sort once per frame).
I see frequent references to Cut.Pin.prototype.absoluteMatrix and .matrix. I will note that these don't appear to create garbage - which is great! - but they silently mutate a shared Matrix instance which means that it is very easy for a library consumer to end up with their state corrupted - if you store the result of absoluteMatrix, then modify the state of a Pin, that matrix will suddenly become corrupted. Sadly the code appears to make no effort to warn users about this.
You're not using any type hinting (i.e. | 0, +) which means that JS JITs will have to work harder to figure out whether given values are integers, floats, or something else. This results in JIT recompilations, less efficient in-memory representation, and in some cases results in floating point/integer values being boxed instead of stored efficiently on the stack/heap.
You mix different types in some of your slots (for one example, Anim._time is both 'object' and 'integer') which prevents optimization in most modern JS runtimes. This can have a catastrophic impact on performance in some scenarios, so you should avoid it if possible. A good way to replace a null/integer pattern is to have an integer that's always an integer, along with a hasValue boolean - this is how nullable primitives work in C#, for example.
Some of your non-initialization code uses temporary object literals - this.pin({ ... }), this._next = { ... }, etc - which is a recipe for bad performance and GC pauses if you're doing it during updates or rendering operations. It's not immediately obvious to me whether you could optimize this out easily, but you should make sure these temporary literals are not being created in large quantities.
You have many functions containing throw statements and a few containing catch statements. In most JS runtimes these both prevent optimization of the function body. You can solve this by hoisting the throw into a utility function (In JSIL I have a 'JSIL.RuntimeError' function that just does 'throw') - this allows the function to be optimized even if the throw-function is not optimized or inlined. When you have a single throw statement in a complex high-traffic function this can matter a lot.
You appear to not be validating or properly type-casting the inputs you pass to canvas.drawImage, which will impair performance and result in runtime errors. I can tell you've already run into problems with this since your drawImage call has a try/catch wrapped around it (YUCK) - the right solution here is to read the spec (that more or less clearly specifies the expected types and constraints for drawImage), and then make sure your code satisfies those constraints. It will be much faster and more reliable if you do so.
It appears that you may have many scenarios where you call drawImage with a source rectangle. This tends to be poorly-performing in canvas implementations (due to deficiencies in the spec), so if you want that to be fast for source rectangles that don't change, you should cache the source rectangle in a unique canvas so you can draw without source parameters. Typically source-rect blits can't be batched at all (i.e. one hardware draw call per blit) so this makes a big difference.
I'm sure there's more, this is just the result of a quick skim of the code. Feel free to contact me if you have more questions. You can identify many of these performance problems by reading specs and using things like Chrome's profiler and Firefox's SPS and JIT Inspector profiling tools.
I'm a huge fan of people sharing their libraries and engines with the world, but if you're going to spout superlatives you need to be prepared to back them up. Otherwise, people who don't know better will be misled by your dishonesty and end up having their efforts at using your tech go to waste when they have to port to something better.