When you gather requirements, you typically interview people, read and evaluate business or technical papers, or you look what competing software already provides or misses. You will get lots of ideas, on lots of different levels of abstractions. If among these ideas and input you find clean, short and precise problem statements, there is no need to inflate these artificially to an "epic". You use an "epic" if you cannot immediately break down the idea for a requirement to a smaller sub-problem, and you use a "user-story" when your input can be immediately written down in form of a "small user story". And thats it.
This is mostly independent from being in a point in time where no software is written so far (what you call "discovery phase"), or a point in time where you already have a working product and can describe any new requirement in form of a change to the existing software (which should be the 99% case in agile). Indeed, when you have a working product of a certain size, it will become certainly easier to describe several requirements in detail by referring to the existing product and writing a small user story which describes the requirement in form of a change request. Nevertheless, even if the product has already lot of features, expect users to come up with new ideas at any point in time which require an "epic" as the appropriate form of description.
Note also that the typical "life cycle of an epic" is that it will be broken top down to user stories which can be developed individually (and not the other way round), because an epic is typically too big to be developed in one sprint. There might be cases where lots of individual, detailed "user stories" inspire an "epic", because one gets a "bigger picture" from a collection of ideas - but it won't make sense to throw the related user stories away then, because you will need them either for the detailed sprint planning at a later point in time.