My web application uses a connection string to access a
database. The connection string is secured and
encrypted... but when the connection is active, couldn't
someone intercept that connection and effectively "sniff"
what is being stored and read?
Maybe.
In a typical small web applications configuration, you'd be running your database on the same machine as your web server and application. In this case, the connection between your application and the database would be protected by operating system, which enforces that loopback address or domain socket can only be accessed from local processes. There's little to gain here from encrypting the connection.
In another setup, you might have a physical wire connecting two machines on the same rack. The rack might be placed in a secured data center in a caged rack, where you're happy with the data center's security parameter, or it might be in a locked closet in the office, and you're happy with trusting the employees not trying to deliberately break into the closet. In this case, adding encryption might be overkill.
In a similar situation as previous paragraph, but now you have an outdated router between your machines. Problem is that this router runs outdated software with known vulnerabilities, or you don't trust its Virtual Networking configuration, or it doesn't support such features, or you're worried about remote take over of the router's web administration. Then you might want to add TLS encryption and mutual authentication to cover up deficiencies in the outdated router.
In another typical case, you might run your database and web server in multiple VMs in a public cloud provider, you might want to add inter machine encryption, or you might decide that the cloud provider's network access control is not trustworthy enough for the kind of data you're dealing with. You might run a VPN between the machines or an encrypted overlay network on top of the existing network infrastructure.
