Very common problem indeed. I faced it many times in the past.
What I suggest (highly opinionated):
If you know that there will be max few dozens editions per conference than go with lazy loading (but try to avoid N+1 problem). Ultimately loading 50-100 records from DB only when editing something is not an overkill.
If the above is not the case (e.g. there are thousands entities under aggregate root) then consider makeing a conference an aggregate root as well, and utilize a concept of DomainService. My understanding of DomainService is that it contains logic which does not belongs to any AR (in your case, there will be logic that handles both ARs together - conferences and editions). You can then call DomainService logic only with these aggregates you need (e.g. current conference, current edition, new edition) which will eliminate need of fetching all editions of a conference.
Hint: I empirically realized that majority of my entities are Aggregate Roots. There are just rare cases when AR has child entities.
Considering your case again, let's ask question "does it make sense to edit edition directly, without accessing it through AR? I'm guessing YES (e.g. changing edition's promotion. I believe promotion is per edition and can be changed without accessing through AR).
Another example: catalog has sections, section has products. Featured product of a category can only be active (not disabled) product. I'll make all of these a separate aggregate roots.
Edit Consider DomainEvents too https://stackoverflow.com/questions/59583401/correct-way-for-communicating-aggregates-in-ddd