It's different, though. If my web server has direct database access, and it gets compromised, an attacker can go in and directly do "SELECT * FROM users" and get all my data in one go. If the database is behind a restrictive service, and they compromise just the web server, then they have to sit on the web server and pull each user record one at a time. And they might not even be able to, depending on search options -- like they might just be able to do "GET /users/{userId}", and if you don't know the user IDs, you get nothing (our user IDs happen to be randomly-generated 128-bit numbers, so searching through that space would take a while). Even if they
can get past that hurdle, the extra traffic it would require to pull down the full database with one request per user would certainly set off alarms, and doing it slowly enough to
not set off alarms would just take too long.
Of course, another option would be to use the web server compromise to then jump to the database service and compromise that box as well, but, again, more hurdles to jump means less of a chance of success.
Nothing is perfectly secure, but you can design systems with defense in both breadth and depth, and you can slow down or defeat many attackers that way. It's not about making Fort Knox, it's just about making breaking in more expensive than they can handle.