You can't build a secure password reset system without a trusted method of communication. If the provider can't be sure who is attempting to reset the password, they can't be sure that they are only resetting it for the legitimate owner of the account.
Therefore most modern password reset functions are a balance between a certain level of trust and a certain acceptance of risk.
On the most secure side, such as when dealing with passwords to data of very high value or of national interests, a password reset might involve a face-to-face meeting, after verification through multiple steps - maybe at least one person who has previously met the requester, some bio-metric identifiers, and some other forms of identification. This is impractical for most websites.
On the least secure side, you can have a password reset process which consists of checking that the username is correct, and it resets the password. Yes, these do exist. No, they are not useful in the slightest.
In between, you have every existing password reset scheme. You can decide to trust the user to pick a strong email password, and the user's email provider to have good protection in place - yes, some providers are dreadful at security, but others are pretty good. Don't forget that they need to have password reset processes in place too - and that they can't just email the user to verify their identity. You can limit the damage that someone gaining access to an email account can do by having a relatively short expiry time on the reset tokens - an hour might be acceptable, but for high value accounts, 5 minutes might be more suitable. You have to accept a level of inconvenience for users though if you do this - email doesn't always get through instantly.
You can introduce a second factor, such as TOTP or an SMS code. However, it might be less of a second factor than you think - lots of people nowadays receive email on their phones, which would mean that an emailed reset with a code sent by SMS might actually mean that someone has stolen the user's phone. Same with TOTP applications - if the user doesn't set a passcode for them, anyone who can access their phone can get the current code, and will have a short period in which to use it.
You can have a process where users make a phone call and enter something through the keypad. You still need some way of communicating what they enter - if you're a phone company, maybe you can check that they call from a specific line, but if you're not, people aren't going to be impressed if you require them to keep a specific phone number to be able to reset your passwords, and it's entirely possible that you could fake it anyway.
You can ask security questions, but these are generally easy to guess, or they are easy to forget, resulting in the legitimate user being unable to reset the password on their account because they didn't remember the price of the last drink they bought, or the colour of the next vehicle which passes their window.
You can link password reset to a specific device, having a "reset token" stored locally on the device in some way (perhaps HTML5 localstorage) - some online password managers allow an easier reset from a device which has previously logged in than from an unrelated device. However, this can't be the only method you use, as one reason for password resets is theft of devices.
After considering all of these, a lot of large companies who have massive security budgets have come to the conclusion that you have to trust something, and that the best option in terms of balancing security and usability is by trusting the user to have a vaguely secure email system. For high value accounts, they might add extra layers - Amazon lets you have 2FA for AWS accounts, Google has the Authenticator application which you can enable for mail accounts, Steam email verification codes when you log in from an unknown device - but they all essentially come down to needing a method which can verify the user to the provider.
The best option, therefore, is to stick with email, possibly with an extra method from those above. You can even require that the reset occurs from the same IP address as the reset request, although this can cause problems when users are trying to log in on a computer, and get the reset email on their phone.
Alternatively, make it very clear to your users that there is no password reset method. Don't laugh or dismiss it out of hand - for some especially high value accounts, this is entirely legitimate. Some online password managers implement this - they encrypt data on your device, and if the device is lost, and you don't know the encryption key, the data is worthless. It's just random bytes with no method of recovery other than brute forcing every possible password. In that case, you don't need to worry about the user's email being insecure. Although they might email the password to themselves to make sure it is always stored somewhere...