With a proper runtime, you don't bolt caching on, but rather implement it throughout the code base using both local cache state and shared network cache state. The end result is something simpler to implement, maintain, and deploy.
However, thanks to using faster systems, the bar at which you must pay the implementation and deployment costs for caching is much higher than that of someone that needs it just to achieve acceptable speeds at all.
I don't understand why you would want to implement HTTP caching in a language's runtime. Honestly, I don't even see where and how you could even do that.
You don't implement HTTP caching, except in very specific cases.
You cache generated data where you need it. This is 1) Easy to add later, 2) Doesn't sacrifice the flexibility of being able to recompose that data on-demand, and 3) Doesn't require a bunch of complex front-end infrastructure to support.
Yes, and I was talking about implementing caching of components used to compose the pages and API responses, not a full HTTP cache tier that has to be placed in front of your application.
However, thanks to using faster systems, the bar at which you must pay the implementation and deployment costs for caching is much higher than that of someone that needs it just to achieve acceptable speeds at all.