"Load image from URL" just creates an individual texture for the loaded image, and then replaces anything using that animation frame with a reference to the new texture. So yes, that particular feature works as if spritesheeting is disabled: the runtime has no system for dynamically creating spritesheets, that's only done by the editor at the moment. I guess it's theoretically possible the runtime could do dynamic spritesheeting, but the editor spritesheeting system is extremely complicated, and so I would be very reluctant to have to bring that all in to the runtime.
I looked in to some of the old WebGL 1 code, and it's actually more subtle than I originally remembered: WebGL 1 can load non-power-of-two (NPOT) textures, but only if they're not tiled; then there are still some more restrictions that apply to NPOT textures, like being unable to generate mipmaps. If you want a NPOT texture for Tiled Background, Construct stretches it up to a power-of-two size, which slightly degrades the quality; if you downscale a NPOT texture with WebGL 1 and mipmaps enabled, it will have poorer quality as WebGL 1 can't actually generate mipmaps in that case. These limitations tend to manifest as a degradation in display quality on WebGL 1 systems, but that's not as bad as failing entirely, so I guess I mis-remembered that. One of the benefits of spritesheeting is since all the spritesheets are a power-of-two size, it side-steps all the NPOT restrictions that WebGL 1 has, so improves compatibility and display quality.
A good example of "how hard can it be to load a texture?" - pretty complicated in the end when you take in to account old and more limited hardware. All the other stuff about potential performance impact applies though, which will vary depending on the game (it suspect it could range from "no significant impact" to "totally trashes game performance").
So I think this approach might be worth thinking about:
Perhaps there's other ways to solve this - for example if Construct could export metadata about spritesheets (i.e. the location and size of every image), then in theory some external tool could take a folder of individual image files and paste them over spritesheets, and that could be robust against future changes to the project. It would keep the benefits of spritesheets and only need a minor change to Construct, exporting some extra info it already has.