Abusively yelling about things is unproductive, and will be removed.
In terms of actual technical tradeoffs,
You are only looking at one part of the issue, and ignoring the other part.
For most users using the module as intended, a small fraction of a second occurring only once every few minutes and accompanied by the much more power costly actual usage of the radio, is really no cost at all.
In contrast, lower power consumption while asleep is very key, but comes at the cost of a slower wakeup process, which needs either a distinct wakeup trigger with a gap before the actual serial data, or a slower baud rate.
This module’s firmware is really designed and optimized for a different usage than you are looking for - it can do custom LoRa schemes, but it’s really designed for LoRaWAN usage where it would primarily transmit short messages infrequently with very long sleep periods in between.
You’ll always have more flexibility for unique usage when you run your own firmware directly against the radio, either on the CPU in this module, or on that in your own. For your rather unique use case, I’d agree that 9600 baud is on the slow side, which is why your needs are the textbook example of a situation where you really want your own firmware, rather than a serial command one that’s optimized for the quite different sleep/wake pattern of a LoRaWAN node.
Aesthetically, I also dislike the idea of 9600 baud even for LoRaWAN, but after looking at the tradeoff in detail, it’s actually the better choice - I’d call your attention to section 3.6.9 of the STM32WLE5xx data sheet which documents the exact baud rate limit for the LSE-clocked wakeup mode of the LPUART as already explained, and section 5.3.8 which gives wakeup times from stop mode which would be hard pressed to capture the first bits of 115200 baud traffic without a framing error, unless a faster oscillator were left on (costing power) or some other pre-wake scheme were used. Each chip which could be used in a product such as this offers its own unique sets of tradeoffs - an improvement in one area has a cost in another, and one doesn’t always agree with the designer’s choices.
The LPUART wakeup is a clever enough solution to a problem I recently faced on an other project that I’m going to keep it in mind for a future strategy, since it allows getting a very low power sleep without needing to impose any particular behavioral rules on the interacting code.
