Storing the username and password - Ultimately something has to be stored, and an access token can be used to access resources just as easily as a username and password.
That's one point of view, but the other is that it allows you to use the "id" scope to log in to other systems that don't even care about your salesforce.com data, but use the information in the "id" scope to uniquely verify who you are in the external system: it's a form of single sign-on. Imagine you have 20 systems you use on a weekly basis. Would you rather remember one username and password, or 20? Using OAuth as a single sign-on mechanism can save a lot of headaches.
As an example, when I worked at salesforce.com, I had a unique username and password for every instance on salesforce. That's right, na1 would have one username, while na12 would have another. Most of the time, the SSO worked well, but we had to keep resetting our passwords, and it was very burdensome. If only they'd been using OAuth back then, it would have been far less of a hassle. It's been about 8 years since then, but I could imagine if they still had the system in place, that means that employees would be required to maintain over 50 usernames and passwords just to log in. That's not practical, short of using a password manager.
Connected apps provide a mechanism for restricting access - Restricting permissions on the integration user's profile works just as well or better.
Those permissions apply to the user, not to the application. By using a restrictive scope, it allows users to expose only part of the functionality of the system without having to restrict their access across all systems. For example, if a site wants me to log in with the "id" scope, I know that it can't perform a full data export using my admin credentials, without me having to use some other restricted license just to log in to the other system. For your own external systems, you won't care anyways, because you're using the "id" scope simply to verify who they are, at which point you'd issue them a session based on that information.
OAuth flows let you revoke the access token without needing to reset the password - Either way, it's just one click in the UI. For a dedicated program that only accesses salesforce for this purpose, there is no additional hassle revoking an access token and setting up a new one vs. refreshing the password and setting up a new one.
Actually, that's not true. Again, it's the difference between revoking access to an application, and revoking access to all your applications. Going back to the prior example, if you have 20 clients that all used a password-based system, you'd have to reset your password, and then update that password in 20 different places. Using OAuth, you reduce that need to resetting a single password. As another example, let's say your phone is stolen; you can revoke access just to those apps without revoking access to every other app you use on your desktop.
Ultimately, OAuth is a tool. It's something you can use to make your users' lives easier. In the case of your own applications, you can choose between OAuth, LDAP, SAML, or whatever makes sense for your organization's needs. What does not make sense, is to require your users to install a password manager just to be able to use your systems effectively.
When faced with arbitrary password requirements, reset periods, grace periods, and so on, it makes sense to utilize a SSO system to make it easier for users to do their jobs. OAuth isn't the only option, but it's a viable option that's easy to implement on many platforms. You use it because you want your users to have secure passwords, and you want them to be able to control access to those systems using a centralized resource. As I said, OAuth isn't your only option, and for many organizations, something like SAML or OpenID might be a better choice, but it's something to consider when you think about your security strategy.
