Jose, first thing to realize is those assets are cacheable in the real-world: a copy will be stored on the user's local hard disk (subject to them clearing their cache, of course, like anything else). This differs from truly uncacheable assets which the server says may not be reused, ever.
However, because of the headers Marketo sends, the freshness of that local copy will need to be checked with the remote server before deciding whether a new copy needs to be fetched, a process called revalidation. Revalidation is way more lightweight than downloading the full asset every time, but it does involve some network-related latency just for the server to say, "You have the latest, just use your local copy."
Ideally, you would apply an explicit expiration date to assets that you are 100% sure will not change before a given date. With explicit expiration (via the HTTP Expires: header), the revalidation check doesn't need to happen, and performance improves. It's a best practice when it's suitable.
But -- and this is a big BUT -- Expires-based caching is not suitable for all situations, which is no doubt why Marketo doesn't employ it. When you say that an asset stored at a given URL expires on July 1st, then once someone gets the copy, you cannot force them to get a newer copy from that exact URL. Yes, if they manually clear their cache or you can pop up a request that they do so, they will get a new copy, but in everyday, impersonal navigation, once they download pages.example.com/mystyles.css that's the copy they'll be using until it expires.
When you use Expires-based caching, you can't forcibly push a new asset at the same URL, so what you do is tweak the URL slightly to create a different version. pages.example.com/mystyles.css?version=212 will load fresh from the server even if pages.example.com/mystyles.css?version=211 is cached. As you can see, this means you need to do much more intensive change management on your LPs relative to just replacing the asset in Marketo. I'm not saying it wouldn't be worth it, but perhaps you can see why the average non-technical Mkto user would find this cumbersome, especially when replacing multiple assets.
All that said, you can use a CDN to serve your LPs and set the CDN to forcibly add an Expires: header. We set seemingly static files to expire in 12 hours, which means inside of that 12-hour period it would be painful to update styles or images, but as long as we can handle that delay, we can use regular asset replacement and still get the benefits of Expires-based caching.
