All members of the staff -- environment artists, character artists, level designers, animators, FX artists -- are all very technical and have the power and wisdom to use the framerate wisely.
I'm not even sure why you're bringing up frustum culling -- you're suggesting that we have too many objects to run the cull math on so we schedule across frames? But we don't; that results in visual popping. If culling is a bottleneck, we usually solve by broad-phase data structures like octrees, or ask the artists to condense multiple separate models into one so we have less objects to manage (another big cheat, artist labor).
Games are not using complex scheduling and multithreading to achieve acceptable performance updating 2000 entities. You can achieve that easily on a single thread by laying your data out to take advantage of locality of reference and the CPU cache.
What games do is fundamentally different than what react is doing here. In games there are many places where you can trade off quality for speed (for instance frustrum culling). You can decide to compute less to fit within your computation time slice. Likewise, physics can take into account the update rate to adjust to the CPU/GPU's processing capability (i.e: you can use a delta_t in your computations to adjust for frame differences).
In the website there are some such opportunities (you could do it with animations for instance), but you cannot do it in general because most apps logic would not tolerate it (yeah sorry I dropped your request callback bad luck). For this reason I would be very surprised if React went that route.
And frustum culling has nothing to do with this nor it reduces any amount of updates.