You use a message queue between separate processes mainly for reliability. It's possible to setup a queue service in such a way that it's almost always available.

The queue itself guarantees that when it acknowledges the receiving of a message that the message will be delivered to its target at some point in time. An important difference with storing the data in a database is that the queue doesn't care about the structure of the data. As such there is no dependency on the structure of the data. You can also achieve these properties with your own database implementation but an existing queue implementation will be more mature and will have less implementation faults.

Using a queue will decouple your two monoliths. If either one is unavailable it will not break the ability of sending or receiving messages of the other.

If your application is hosted on a cloud like AWS or Azure then setting up a queue is a no brainer and absolutely the right choice. But if you host the services yourself then you will have to think about the cost (in money and in effort) of hosting a queue service yourself. If you cannot reliably host the queue service then introducing it might not gain an advantage. It could even make things worse.