Arrow is a nice design, BTW, but for something happening in the 22nd century maybe.
This entire conversation about "real" and "physical" shows that Chris really have no idea, which is surprising given how much software he wrote in his life. He should understand that code is just a bunch of abstractions and metaphors translated by another bunch of abstractions and metaphors into flows of electric current. It is the ultimate theatre of smoke and mirrors. On every level. A "connection" is just an abstraction over a certain pattern of messages in the network. A database "transaction" is just a pretend, nice-to-have abstraction that requires crazy amounts of implicit pretend and cleanup underneath.
And yet he seems to be stuck with a more expensive version of the naive notion that "tricks" are something to be avoided. These are not "tricks", they are techniques of making sure that at the end of the computation, the image and the sound produced by a player's computer, create enough of an illusion of alternative reality for the imagination to kick in and fill in the rest.
You're confusing abstractions with approximations. They're not the same thing, logically or practically in a development sense, but in general I think I agree.
What you're actually getting at is that for a great many systems the amount of approximation (getting something that looks and feels about right in a simulation even though it's a kludge) isn't enough to be practical, and we are instead seeing systems implemented at a level of complexity that just make the overall job longer.
Lets for example take ship maneuvering thrusters.
Elite
approximates this by having thrusters about the ship that fire when the ship moves based on a simple 'yaw, pitch, roll' stat trio. The individual thrusters can't be damaged, can't be altered (altering the thruster grade basically tweaks the YPR values), the centre of rotation of each ship is fixed. It's a kludge, but it works, it's neat enough, and it doesn't actually need to be anything more. Ding ding, point to Elite.
Star Citizen handles this by having each individual thruster gimbal to provide thrust based on an actual centre of mass. Knocking out thrusters on one side actually stops them from working and feeds back to the maneuvering of the ship. The abstraction method provides a location for thrusters relative to centre of mass, force of the thruster, etc. etc. It's super complicated but allows for great depth of simulation. But all that setup needs to be done*, for each and every ship. And at the end of the day, in most situations, it won't behave any differently (other than the thrusters wobbling like a spastic violin player's elbow).
*: This boils down to back-calculating the thruster values from playtested YPR values for the ships.
The questions of 'Do you actually need that?' 'Is that actually fun?' 'Is it worth the time and cost?' are often perhaps answered in ways that we, as either players, or customers awaiting their product might not.
Edit: It bears repeating, I do not class Star Citizen as a game yet. Yes, I've spent money on it (quite a bit, for me, for a game/plaything). I did that knowing I was funding CR's insane fever dream - and that's the important bit. I paid to watch the madness unfold. Don't buy into it if you want a game to play, or at least, certainly don't spend anything you'd be upset about. I've not actually spent that much time on Star Citizen. I've done a few things, looked at others (now need to rebind all my controls which will take a frickin' age). It's a testbed of a developer given almost completely free rein, and it shows 'where could things in game development go' if anything more than 'where will Star Citizen / S42 itself go'.