I think both the statement and the criticism are oversimplifications.
It sounds like the criticism hints at the hidden node problem. (Briefly: One of the largest problems in wireless networking. A and B can hear each other, B and C can hear each other, but A and C can't. So when C wants to talk to B, how does it know if A is already transmitting and B's receiver is already listening? In large networks this gets hugely important.)
But it sounds like the simulation is already maximally pessimistic about it -- there's no RF attenuation in the drawer, so all the devices occupy the radio channel whenever they're transmitting. So I would imagine that software that works well in this case, would probably also do decently in the real world. (As opposed to software tested on a naively-simplified network of RF cabling and attenuators, which would not model the hidden node problem's complexities very well.)
So, while the real world will surely be more complex than they hint at in their sentence, I think the simulation drawer is also better than you hint at in yours.
There are nuances, of course, and frankly there are RF network simulators they could be using, but I think the presented MAC-filter approach is not terrible.
OP of the article here. You are absolutely correct. The statement in the article is very much a simplification: in the real world, wireless communication is tricky. Not only are there issues such as the hidden node problem (and the exposed node problem, for that matter), but it also changes over time.
It is possible to take these issues into consideration, but as you say, that requires a very different infrastructure than what this article is talking about. The way we do it at Thingsquare is to use a software-based simulator where we can both emulate the software on the devices and have full control of the simulated radio medium - if we need it. Sometimes using RF attenuators and/or cabling is useful.
In the end, what it comes down to that each tool has one or more use cases where it shines, but there is no one tool that fits all.
I'm not a HAM guy - would you care to distill the lesson that they are ignoring? I infer that, by definition, this is not a mesh, but more of a train. And I further infer that a single node falling out would break the chain and split the "mesh". But I'm just guessing.
It doesn't say how many nodes could hear each node in the emulated env, only that's it's a subset of the total, unlike the unemulated env where they're all in a drawer. There's nothing there that precludes having enough for nodes to route around failures as I see.
And I'm out. Mesh networkers really should spend a bit of time re-learning all the lessons from decades of ham radio packet networks.