There are times when an attacker might have access to retrieve data from your database (e.g. SQL Injection) but not have enough access to extract the encryption key from your web.config. In these situations this practice would add another layer of defense against user credential cracking.
It definitely isn't foolproof since a compromise at the server OS level could allow the attacker to extract encryption keys along with the user database. An attacker might also be able to run commands through SQL injection that provide access to the web.config data.
Whether it's worthwhile is a judgement call you'll have to make. It will add some overhead and complexity to your authentication process for a slight security improvement. If your credential database is compromised you will be able to tell your users that you don't think their passwords were exposed -- assuming you know for sure the key wasn't stolen -- but you'll probably still instruct them to create new passwords to be safe.
Adobe encrypted their customer passwords, and while millions of them were leaked a year ago there still hasn't been a public disclosure of the encryption key. These credentials might still be considered protected if it weren't for the accompanying password hints that often blatantly explained what likely password was used.