Many years ago (2016 I think) I needed a way to send commands to a relay attached to a RPi in my garage to open the garage doors. I also had reed sensors that report the open/closed state of the garage doors. So I wrote a Python script I call sensor_reporter that runs on the RPi and reports the sensor states and triggers the relay when it receives messages. Over the years I and others have continued to improve and add to it so it now supports all sorts of BT stuff, DHT sensors, executing command line commands, Amazon Dash buttons, etc. Some of this is duplicative of what is already built into OH but I wrote them before OH had those capabilities, or there are other reasons why I don’t want to do it on the OH server itself.
For the Govee BT stuff, I found an example on GitHub that was actually written for Home Assistant that parsed out the readings from the BT messages. So I took that as an example and adapted it work as a sensor in sensor_reporter.
Basically yes. Unless the device goes through some effort to encrypt the messages BTLE broadcasts can be sniffed by anyone. I can’t claim credit for figuring that stuff out though, as I said, I had an example to work from. The “posted on an MQTT [topic]” part is already built into sensor_reporter. That is based on code I originally wrote five years ago (recently refactored).
MQTT has some advantages that make me choose it over other options most of the time. In particular the LWT and careful use of retained messages and the fact that it’s a standard not tied to any specific home automation system makes it very powerful. But sensor_reporter has another openHAB communicator that uses the openHAB REST API and SSE feed to send/receive Item states. However, because of the dynamic nature of the Govee add-on, I don’t have a good way to use that communicator with it so for now MQTT is the only choice for that specific sensor.
I wrote sensor_reporter to be modular so I only have to figure out how to do things once. So it has a core that is reused by everything. Communicators are independent so with the one exception it doesn’t matter what sensor_reporter uses to send and receive messages. Thus, to add a new capability to it just requires figuring out that new capability and all the rest (loading the configuration file, figuring out how to send and receive messages, running as a service, handling signals from the OS, thread management, etc.) is already done for you.
There are other programs on github that do this too, but mine was first. 
The openHAB Android app has integration with Tasker so no need to mess with MQTT or the REST API directly. But if you didn’t/couldn’t install the openHAB app, you can also use the REST APi directly. See Triggering Items Using openHAB 2's REST API from Tasker for one of several tutorials.
With the AutoInput plugin to Tasker it’s possible to scrape the currently running app’s UI and extract information. For awhile I had a profile that would scrape my estimated arrival time and send an SMS to my wife when I started my commute home. Assuming these can all run and interact with the apps required it might work.