Latency vs Rate
a low-latency (10 Hz) type of IoT application
This is a conceptual error. Latency and Rate are largely independent. You could have a system which recorded thousands of readings per second, stored them on an SD card, and once a month someone visits the remote site, extracts the card, and mails it to you - that system would have a high rate but also extremely latency. Or you could have a system which reported readings within a few microseconds of when they are taken, but only took one reading per hour.
So the first thing you will need to do is to clarify your requirement - do you need to take a lot of data, or do you need to get it while it is still very current, or both?
A 10 Hz update rate is relatively workable for most digital transmissions schemes, except for those where there is a regulatory limit on the number of transmissions per period of time, or those which have such a low data rate (either because they are narrowband for link efficiency, or because they are crude) that they just can't move the amount of data you want to send quickly enough.
Latency vs. Reliability and Complexity
As the actual propagation time in small areas requires exotic circuitry to even measure, for local radio systems the time taken to move a message is basically the length of time to encode it - unless system design aspects add more. A system which needs to do a lot of "contemplating" of a message could add delay, though with decent software that is likely to be slight. One which requires a number of back-and-forth cycles of "discussion" per message necessarily increases the time by the number of cycles and any turnaround time of the link or protocol.
But the most likely source of delay is a Reliability Layer - if a message is missing or arrives corrupted, what should the system do? If it tries again, that almost invariably means adding delay, while if it just drops the message and moves on that may mean gaps.
For your kind of application, what may work well is an unreliable scheme, but one where each packet includes not only a current measurement, but repeats of a few previous ones (or for a counting application, a running total). And those don't necessarily need to be the most immediately recent measurements - depending on patterns of interference, the best scheme could easily end up being something like current, previous, next previous, 5th previous, 13th previous, or whatever, so that the packets that do get through tend to have a high chance of also including the data which did not.
Practical Systems
Many off-the-shelf 2.4 GHz systems would probably work fine in your example, if there are reasonable sight lines or leakage paths between the components.
nRF24L01 - style 2.4 GHz digital radios would easily handle the data rate, and are readily used to make fairly low latency channel hopping systems - for example, these and their competitors are used to interactively fly many inexpensive consumer drones.
BTLE has modes with state complexity which could be problematic, however the advertising mode is simple enough and can be run at the kind of repetition rates you are seeking. Custom receivers built around embedded boards as your propose should be able to keep up and give you the full details of each packet. There is also some cross compatibility with smartphones, however in that case the host operating system may give you only a small minority of the traffic, and may not consistently inform you when the packet contents change.
there are of course many other choices
