Normally, the procedure that you specify for enabling the role will implement some additional validation. For example, if you had a table of application users, you might do something like this (though, obviously, you would store a password hash rather than storing the password in clear text)

If you design things like this, you can connect to the database using a shared account that has only CREATE SESSION and then whatever application username & password the user enters determines whether the session can enable a role that allows the application to do something interesting.

A password-protected role is another way of managing security. There are cases where a password-protected role can be helpful but they tend to be relatively uncommon. If users know the password to be able to log in to the database using whatever account the application logs in to, it can be useful to have the application enable a password-protected role so that users logging in via SQL*Plus can't easily figure out the password. But that assumes that you can successfully keep the role password private when you've failed to keep the database account password private which isn't particularly common. There are probably cases where organizations are trying to add appropriate security to an environment that hasn't had it where this may be a useful transition strategy.