I think we're ignoring a painfully obvious risk of people losing access to their account because of the change. Loss of access is a DoS security risk via introduced downtime. My organization has quite a few employees who do not own smart phones, and a few more who don't have cell phones altogether. Legally, we cannot require this. This will cause a business loss for us in lost hours on support calls due to and as well as users losing access to their account. Many users are begrudged to install an app on their personal smartphones, which we also legally can't require them to do. Most businesses DO NOT pay for every single employee's phone, and therefore have no right to require its use. If it's a convenience, they can pay for it, but if it's a requirement, we have to.
Furthermore Notification with only an Accept requirement is painfully insecure due to notification spam. michaeldehaas is right on the money here - I know of a few instances where this has occured. Simple Accept notifications without a code are not secure, and IMHO barely qualify as MFA. OTP via authenticator app is also secure, but also easy to lose access to, and I deal with these kind of calls all the time. After loss of OTP devices, if organizations will work with you you're introducing a commonly accepted excuse into the social engineer's playbook. The bigger the org, the less secure this move actually is in reality.
Security posture isn't something you can enforce via monolithic policy - it's something you convince the user to do. If you install complicated locks on a door that take forever to use, the user is more likely to simply leave the door unlocked entirely.
The appropriate course of action is to get rid of the SMS, but not the phone call. It's much more difficult to intercept an actual call than to sniff the air for an SMS message. Most phone carriers use VoLTE for cell calls, and by default, all VoLTE calls are encrypted. This would encourage users to use the app and avoid using their PSTN whenever plausible. Sure, they can still socially engineer the phone company, or perform a SimJack, but both of those instances put liability on the phone company, not the business itself, and both are likely to trigger a response from the victim. You can't make perfect security, so you want your design to be such that breaches of security to produce obvious effects so that it can be dealt with swiftly, before evidence is lost, or the impact of the breach gets out of hand.