Yep, it's pretty common to want to load only the images needed. It's quite a bit more complex than just loading the textures though. Any app where loading all the textures can work should just do that.
The next step might be to pack atlas pages (see folder structure) carefully to group images that need to be loaded at once on the same atlas page texture. For example, this might be per level, since you probably don't need to load all textures for all levels at once. You could even duplicate some of the common images on the atlas pages.
Most complex is using individual image files and packing at runtime. It takes some doing: you need to determine which images you need based on things like the character's equipped items, items they can pick up during a level, all animations that will be played and what images they need if they show new attachments, etc. Once you figure out the images you need, you need to download them and assemble them into an atlas. Finally you can configure the attachments with the atlas. None of these steps are particularly difficult, but it's a fair amount of work.
If that's not complex enough for you, to get really fancy you could use SVG instead of images. Everything is the same except you download SVG instead of PNGs, then you rasterize them somehow at the right size (probably based on the user's screen size) and then pack those images into atlas page textures. The benefit is mainly that SVG files are much smaller than PNGs, so you could have 10s or 100s of thousands of images.
To make it harder than that, you could try to render the SVG directly and not use images at all. 😃 Instead of setting the attachment renderer object to an atlas page region, you'd set it to the data needed for the SVG. Rendering vector is difficult though. Often only a subset of SVG can be supported, and then you need to handle when you artists inevitable use unsupported features.