Executives and clients like to see timelines and total project estimates. I wrote an article* about this. The idea is that you do some rough planning, applying the principles of Agile story point estimation, and extrapolating a rough/relative timeline.
Relative timelines with non-specific dates are useful for getting an idea of the scope and possible time of a project. Helps determine what should be built first, prerequisites, and what other teams might need to be involved (and at what stage). Also useful to get the product managers or executives thinking a bit more deeply about the project and perhaps reconsidering it, or reducing scope if it looks like it will be larger or take longer than expected.
Once a project is kicked off, after a few sprints the initial plan can be updated based on the actual velocity of the team.
* https://jonpurdy.com/pm-framework/how-to-quickly-plan-and-es...
Of course, you need to know the direction of the project. But spending time on details that you cannot directly validate with implementation, risks both wasting time because of invalid assumptions, and risks wasting time because the requirements may change when you get around to implementing it.
Remember that "planning a sprint" gets very deep very quickly. It's not just about setting direction, it's about deciding display names, storage types and UX interactions. The point of the article is that that level of planning should not be done months in advance.