I took chances with the nRF52 family, specifically Fanstel modules, but you can easily just use the nRF chip as is. Some key findings so far:
Hardware design and documentation is just excellent. This is the easiet-to-program (on register level!) MCU family I have ever used - including the RADIO peripheral!
As a massive contrast, the SDK / official software ecosystem is one of the most horrible, most complex jobs ever. Simplest of examples compile tens of thousands of LoC, and do not work out of box. You can't even get hello world, because hello world is printed using a custom NIH "logging library", which requires configuration (10kLoC configuration file) to work. I spent hours trying to fix the logging library and gave up.
In the end, I just needed radio comms (and had quite special custom requirements regarding timing and bandwidth), not compatibility with Bluetooth devices, so I did not use the Bluetooth stack at all. Went bare metal writing custom code for the RADIO peripheral.
I started with the Enhanced ShockBurst example - that was actually possible to compile and use, worked almost out of box. The next step was to modify ESB example, changing the radio into BLE 125kbps LR mode - it requires a few modifications. But do beware - ESB is nothing special, it's quite primitive. You can easily surpass it with your own protocol. For example, adding resends and frequency hopping greatly improved the performance over the ESB example.
For a simple one-off, you can go pretty far by something like this:
typedef struct __attribute__((packed))
{
uint8_t len;
union
{
own_payload_type1_t own_payload_type1;
uint8_t payload[250];
}
} packet_t; // remember to configure the packet structure in NRF_RADIO peripheral, so it automagically knows how wide len field is, maximum length of payload, etc.
packet_t packet;
packet_t.own_payload_type1 = {1,2,3,4,5};
packet.len = sizeof (own_payload_type1_t);
NRF_RADIO->FREQUENCY = 42; // 2442MHz
NRF_RADIO->PACKETPTR = &packet; // the peripheral understands the len field in memory, and uses DMA to send the packet. Quite neat.
NRF_RADIO->TXEN = 1;
// poll for NRF_RADIO->EVENTS_DISABLED, or make it an ISR
This example shows how easy this is to use!
Of course being who I am and preferring custom solutions, I ended up writing a full fancy protocol with pseudorandom/controllable frequency hopping, message buffering + resend requests, multi-slave timesharing etc. And I don't know if that made any sense, it took a couple of months in the end. But one thing is sure: the peripheral (HW) design and datasheet made the work much less painful than dealing with STM32, for example.
nRF52 devices also have decent PWM peripheral (seems to have 4 compare registers) so it should be able to drive a motor if you use external half-bridge gate drivers with deadtime generation. It seems the thing does not have internal deadtime / negated outputs.
But, regarding your reliability concern with braking - ISM bands is, by definition, out of question. You can't, and I can't stress this enough, by definition, build anything with delivery guarantee over ISM bands. This is because ISM is defined as frequency band not designed for communication; it's the band designed for interference from microwave ovens etc. The fact people started to communicate over a non-communication band tells an interesting story about the misery of political regulation, but that is what we need to live with.
The best you could do is send a lot of small packets, frequency hopping over the whole band, but the problem is, any other device is allowed to wipe out that entire band any time. Then you must rely on physical separation, but how much is enough, this is hard to say.