Great question. The caching will avoid _executing_ the display method unnecessarily. Since most display methods have some SQL query behind it (even if it's just a simple ::find()) this can quickly become a big performance improvement to cache just from a SQL perspective alone, since it would execute the method (and by extension, the SQL queries) every time a control is rendered on the form. So on a grid, this would be a lot of times (every row) and sometimes just a redraw of the screen (in AX2012 for example when resizing the form) could cause many calls and refreshes.
I'll admit I'm not sure what kind of caching is done in the browser versus the server. But I think even if the caching is on the server only, the AX7 "client" in the browser only receives data updates when there are changes (i.e. it already has a built-in sort of caching/buffer mechanism) so avoiding the server to invalidate the cache on some fields should automatically avoid the data being sent back to the browser constantly. I may be butchering the actual implementation or details here, but I think it's a fairly good way to think about it.
So yes, it's very much still relevant - for server/SQL performance as well as User Experience in the UI. With the connection between server and browser being further apart (cloud to local browser) than the traditional AX2012 client/server (typically on same network) as well as internet-connected clients potentially being on less reliable or low-bandwidth connections, data traffic (roundtrips) reductions are important.
