goldentreee what you are asking is a very big issue, I'll try to explain why in the easiest possible terms. Please Ashley correct me if I'm wrong.
Let's start by saying that one of the biggest issue in Javascript is the lack of an explicit memory manager (there are project that aim to fix this) so everything relies on the browser. Modern browser have complex mechanisms to manage memory.
BOTH in webGL and canvas, construct requests the sprite images at startup (when the loading bar is on), at that point a browser makes note and says ok let me manage it, in the case of Ejecta (same goes for cocoonJS) instead those sprites get loaded as textures into memory right from the start! This produces a huge memory spike and with lots of sprites it can end up in the app closing (iOS has a memory manager that halts applications that perceives are hogging system resources and memory spikes are one of the triggers for halting).
Currently Ejecta doesn't have any explicit (or implicit) method to free a texture from memory (see here github.com/phoboslab/Ejecta/issues/166) this means that you have to be extremely careful with what you are loading into memory (see here: scirra.com/blog/112/remember-not-to-waste-your-memory).
As far as webGL goes the issue is still there, Ejecta apparently supports layout by layout loading, but since the images are decompressed into memory at startup is completely useless.
What Scirra could add is a concept of Atlases of images that get explicitly loaded at a certain point (with an action), you can do it right now by using the request from URL action on empty sprites, requesting a local image, I did that in my iOS game for loading of larger images, just know that there is a slight delay.
I hope I've been clear and precise.