The system I recently put in allowed for that 450ms, the time broke down to:
1) NFC comms ~100ms
2) Network comms ~50-100ms
3) Physical relays (releasing barriers etc) 100-200ms
During peak periods the usual rate expected is 30-40 passengers through a gate/minute, which includes all of the time above, plus the passengers actually walking through the barriers (usually ~2m).
The barriers at rail stations have to have a defined maximum throughput of passengers, because it affects safety during emergencies etc. Most barriers are required to maintain somewhere between 30 and 45 passengers per minute.
Yes they can "default be open" and usually have emergency modes that disable validation entirely, but the speed during peak hour periods has to maintain the passenger flow.
You make it sound like less moving parts are a bad thing :-)
I know what you're getting at though - the decentralized tolerance of network partitions and the ability to provide higher availability and faster decision speed at the entry barrier.
The system design constraints are hard but not impossible, my back of napkin maths says 5k/ticket scans per second with 99th percentile latency < 1000ms not only satisfies every use case that exists today but allows for 3x population growth beyond!
There's a few things in your favour when designing this system though. For example, in the case of network partition, you have geographic locality so a pen drive delivered a couple of times per day is likely feasible.