There are 2 caches in nextjs. The client side cache and the server side cache. In next 14, all routes, fecthes, and route handlers cached by default meaning it would fetch the data or build the route at build time once and would show the cached result to everyone. Nothing wrong with this but for many applications, especially when it comes to user-specific data, you would want to show fresh data whenever the user visits the page. So it makes sense to make that the default. Nothing wrong with making the page static/cached. Just depends on your usecase.

Then there is also the client side cache. In Next 14, there is a 30 second client cache so that when a user navigates back and forth between pages, it will use the cached page/data instead of rebuilding the page every time. This can make the app feel fast after the first initial visit but if your app relies on data that is updated frequently, you run the risk of showing stale/old data until those 30 seconds are up and the page updates.

No option is wrong. It just depends on your specific use case.

I think the suggestion I've drawn from reading docs/X is that basically caching is something people more often want to add than remove.
If I write a fetch call, I probably at a naive level expect it to go to the URL I give it and fetch stuff from there.
By making it non-cached by default, it's adhering better to a principle of least surprise.

It's also looking like it's going to be increasingly easy to opt into caching without requiring digging through the thousand options at https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config soon

And accompanying unstable_cache, React.cache, revalidateTag, etc etc