I have always been taught that one of the most important things to do at the beginning of the developments of a software is the Requirement gathering.
Well, in more than three decades of software development I have made the first hand experience that detailed requirement analysis (if you mean that by "gathering") is only really important for developing the next feature or feature slice of a software, and these features should not be too big (that's why you should try to cut big features down into slices). And over these years, this experience has also reached the mainstream and has become part of the so-called "agile" methodologies. So whoever taught you this, it seems they told you some outdated academic stuff from the past.
So the answer to
Why do we spend so much time gathering detailed requirements at the beginning
is - "we" don't, only theoreticians from the past do, who have no own experience in effective software development, and most probably don't know what agile development means.
Of course, there are sometimes sensible reasons why a lot of time should be invested into requirement gathering at the beginning of a project:
because you need to make a fixed-price offer to a potential client. When calculating the price, you don't want to overlook a requirement somewhere hidden in one half-sentence of page 42 of the customers wishlist which takes several additional months or years to develop.
or, if you are the client, you want to make sure a potential contractor will develop all the features you expect from him for a certain amount of money, so you make a detailed requirement list for the contract.
because you need to make some architectural decisions about the system beforehand, and you don't want to overlook a requirement which collides directly with the chosen architecture
None of these reasons, however, expect requirements not to change over time, or each and every feature of the software to be analyzed in every gory detail before you start writing the first line of code. For example, if you make a contract with requirement 1 2 and 3, and requirement 3 is replaced by requirement 4, then this is a good basis to re-negotiate the contract. Or take architectural decisions, these are typically founded on some general notion about the non-functional requirements, those don't become inherently wrong because functional requirements change, and they don't become wrong if the non-functional requirements change within some reasonable degree.
Another point I would like to mention that "gathering requirements" does not necessarily mean an analysis in detail. It is always a good idea to constantly collect ideas for new features and improvements in some backlog or issue tracker throughout the whole project, not exclusively at the beginning of a project, but parallel to the development activities, whenever one comes up with a good idea which could improve the product. This is indeed an important part of requirements management, since it will allow you later to make a decision which of these ideas should be priorititzed, which are beneficial enough to be analysed in detail and implemented as new features.