Expiry is the feature, not the limitation
A file share exists for a moment: a video too large to email, a design handed to a printer, a dataset going to a contractor, photographs sent to a client. The need lasts days. The link, on most services, lasts as long as the account does - and links get forwarded, pasted into tickets, quoted in email threads and archived in places nobody remembers.
Setting the expiry at upload time means the decision is made once, while you still know what the file is and who it is for, rather than never. When the date passes the link stops working and the file goes, which is the outcome you would have chosen at the time and would certainly not have remembered to arrange later.
Why the link is on a different domain
Shared files and short links are served from a separate domain to the one running the app. This is not cosmetic. Any system that hands out URLs pointing at content other people supplied eventually has one of those URLs used for something abusive, and the reputation damage from that lands on whatever domain served it.
Keeping that on its own domain means a blocklist entry earned by a stranger file cannot take down the sign-in page, the account pages or the tools. It is a design constraint that costs nothing to explain and would cost a great deal to retrofit after the first incident, which is roughly how it came to exist.
A link is not a permission
Anyone holding the URL can download the file. There is no per-recipient access, no viewer list and no audit trail, and that is true of essentially every link-based share including the well known ones - the link is the credential, so forwarding it grants access to whoever received it.
Treat it accordingly. For anything genuinely confidential, a short expiry limits the window rather than closing the hole, and the ability to revoke early is what you actually want when a link goes somewhere it should not have. For material that needs real access control, you want a system with accounts on both ends, not a link.