One of the trade-offs of asm.js is that it uses malloc/free style manual memory management and thereby sidesteps GC. More pauses for the programmer in exchange for less pauses in the program.
Technically this is false, as some asm.js compiled games will actually be running their own GC inside the asm.js environment and will still suffer GC pauses - except now it's all single threaded and using a smaller heap so the performance is worse.
Unity is one example of this - they use the Mono runtime and their scripting is based on .NET so browser-targeted Unity games will have GC pauses even if they use asm.js.
The same could be said for using object pools. No need specifically for asm.js. ATM asm.js is used primary for supporting large existing C/C++ codebases, not trying to get free performance gains in your game via premature optimizations.
