This technique is for controlling access to a database, not so much controlling what is done with that access. There is a difference particularly as very few externally facing applications will use individual user access levels enforced at the database level, usually in the application layer. Therefore in the above scenario what is being protected is the application's connection to the database, what the application does with this is up to the application.
As a general security management principle it is best to never assign direct access to a resource and to instead use security groups to manage access to the resource. While this does reduce immediate visibility of users it is a much more manageable scenario. If you're every worked anywhere near ops you'll have frequently come across the, understandably sensible, user access request "give the new starter the same access as the leaver", or anything similar to this. If you assign direct access to resources you will never be able to fulfill this request because in order to work out what access the original user had you would have to query every single network object or node you can find (and this is AD, not NetWare). For similar management reasons, if users may gain access to a resource, such as an MS-SQL database, and later lose access to this resource, something that happens routeinely in larger organisations with internal team, project or departmental changes, then it's often the case that they will gain or lose access to multiple resources at the same time. If these are security group controlled then it is a relatively simple matter to switch access and most sane security topologies have a concept of permissions groups and groups of permission groups :). In other words, you assign access to the resources themselves using security groups and in turn group these security groups together to make management of them as a whole easier. For example if a single application requires access to two databases and one file share then this is a good way to both manage this and to record clearly in the configuration that this is the case: AppGroup contains Database1, Database2 and FileShareA permissions. It is, of course, possible to assign AppGroup access to each of these but this loses visibility of what is actually being secured and while using groups like this adds some boilerplate for non-tin-pot setups it is invaluable.
While web.config connection strings may be encrypted, for a few technical security reasons it is generally considered to be more secure if the user that the connecting process is executing as uses its credentials to access the database and does not use a separately managed, possibly non-standard strength, MS-SQL server login that may or may not be transiently encrypted in the configuration file. There's nothing stopping you encrypting an integrated-auth connection string of course if you really feel like hiding things but "security through obscurity" only slows miscreants down, it doesn't add much genuine security. Using a separately managed, and therefore outside of normal password management systems, username and login in the database server itself adds a likely point of security weakness and it is this that is one of the key factors against using MS-SQL server logins compared to AD secured logins.
...hopefully this makes some sense 🙂