Storing encrypted information in the app's database comes at the expense of inability to use power of SQL to retrieve/store information in a convenient way. Encrypted data can not be indexed.
Because of that in order to search for a specific thing the application's server (or the app) needs to retrieve the whole block of data, decrypt it and then find what is needed.
the encrypted data (e.g. chat message) simply inserted into the database under the respective column and the relational ID is left in plain text
Your app needs a way to retrieve encrypted data related to a certain user. If you store plain user ID, the retrieval process becomes simpler. If all fields of the database are encrypted you lose some usability because data retrieval process becomes harder. You will need to build your own lookup table in the app that would help to store/extract a chunk of data that you need.
But if you store plain user ID and all other data is encrypted and your data transmission process is also encrypted all the way, it should be very hard to map a certain user ID to a real user.
The database encryption prevents data disclosure in case of breach and makes it impossible for database administrators to snoop on your data. So, even if they see plain user ID in the database and can see how many message a certain user sent it is still very hard for them to correlate it to a real user.
How far do you want to go with database encryption (plain vs encrypted data) depends on your threat model.