Nothing is futile, and there are no silver bullets. Everything depends.
There was a sidebar about using disk encryption. That is protecting against a different attack surface, so lets ignore it.
The question asks if it makes sense to encrypt data that is in a database, under the assumption that it needs to be plaintext for a web client. The presented choices are to use a master token (outside of the database) to decrypt the stored cryptotext, or to use a token provided by the user, with the observation that this is a bad idea and wouldn't work for collaboration.
If the concern is that someone might violate the confidentiality of the web server, say to hoover up that stored master token and the database, then indeed you are out of luck. The mitigation here is that often the violation of the database and the violation of the web configs are different, and one without the other isn't helpful. So it is protective in for example the classic example of a sql injection attack dumping the DB.
At that point, using a token provided by the user is very helpful, and I wouldn't call it a bad idea. Note that in theory this can still be useful in collaborative apps: the stored cryptotext can be encrypted using a stream cipher whose key is encrypted (e.g. via a PKI) against multiple people's keys. Now, the confidentiality of the server isn't a problem (assuming that they don't have access to runtime) -- no collection of information on the server can turn the cryptotext to plaintext without the user tokens.
But, if the integrity of the server is in question, then this solution fails. The plaintext is in the memory of the server, so its game over... the program can be reconfigured to persist the plaintext anywhere its desired, or even to change the messaging between the clients. That's where the third solution comes into play. If you have code running on the client machine that does the decryption of the passed information and encryption of any response, you are back in safe water. (Although of course now it is down to the opsec of the end clients, but then that is always the case.)
So evaluate the risks and costs of various cases of loss of integrity at the server, and make your choice.
Sidebar: if you really do care about this stuff, STOP USING PASSWORDS. If you don't, IMHO a master token is fine.