Images are only cached when necessary, that is, when an action is applied to it by Grav. For example, with a file named unsplash_1.jpg in the user/pages/01.home/-folder:
user/themes/antimatter/default.html.twig
{{ page.media['unsplash_1.jpg'].display('thumbnail').sepia().html() }}
{{ page.content }}
user/pages/01.home/default.md
...
# Grav is Running!
## You have installed **Grav** successfully

Congratulations!
...
In the first line of code in the template, we are making the image sepia-toned. This is done dynamically by Grav, so it must be cached to retain it's changed appearance, and results in a path like:
http://temp.dev/images/1/b/5/1/a/1b51a1da4b76fc16dfc4c83f31ef3252abc35a05-unsplash1.jpeg
However, in the page's content, we are accessing the image directly (which we could also do in a template, by not adding any effects) and thus there is no reason for Grav to cache it. This results in a regular path:
http://temp.dev/user/pages/01.home/unsplash_1.jpg
So if you want to ensure SEO-friendly URLs, you'd need to do the processing yourself outside of Grav. I could imagine a system wherein the cache generates differently named URLs, exactly replicating paths from the user/pages/ structure, but it would potentially have to account for a variety of different configurations, which is why the current cache-mechanism is rather more fail-safe.