Absolutely yes.

MQTT is a specific implementation of a general approach to buses. This is wildly used for asynchronous communication between services.

I use MQTT (or other buses) when I have services that need to send some information without consideration for the services that need that information. The first ones are producers, the other ones - consumers.

This is a very powerful approach when you have good cases. IoTs are typical cases where they send data and something else makes use of them. Another example is code that calculates some information and emits its results.

Some of my code retrieve google calendar information and emits that - and it is consumed by a dashboard, some other code that makes decisions such as alarm clocks etc.

In general you use this for asynchronous messaging, especially in with one-to-many scenarios.

(Author here)

I run it to communicate with much more applications. It just depends on your own preferences. For example, some tools provide an API (local or cloud based) and you can directly plug in into that API. In The Netherlands you can read your electricity meter yourself by a "Dutch Smart Meter Readings" and DSMR integrates into Home Assistant with MQTT. I use Z-Wave as wireless mesh technology for lights and switches, the Z-Wave controller integrates into Home Assistant with MQTT.

MQTT is so easy to setup and configure, you can use it for any messaging you want. As an example, I run Home Assistant locally to run my home automations, but also check the status of my local devices and online servers (Digital Ocean droplets). One use case is my backup script which publishes the backup results to an online MQTT server, my Home Assistant checks the topics at that server to display backup stats locally. If something went wrong, Home Assistant notifies my directly. PS. The backup script also sends out e-mails which I filter in Fastmail, the success mails are trashed and only error messages are kept in the inbox ;)

In my experience MQTT works well for telemetry and one-way messaging, but it's not good at doing request-response flow like you typically do in an application using HTTP. You can certainly come up with a mechanism for doing that, but you're having to re-invent a lot of what HTTP already solves.

Sure. However if you are thinking for server/cloud usage, I would recommend considering AMQP instead (RabbitMQ etc). Especially if you want a "worker" type model with horizontal scalability for job processing, then the roundrobin.

Some of the functionality has been added to the MQTTv5 spec, but client support is not as good for that yet, and its not as battle tested as AMQP.

MQTT is just a tool for publish/subscribe; that pattern exists in way more domains than IOT. Facebook Messenger, for example, is implemented on top of it.