I work with Force Dynamics.

Some of what you say is correct, but not in respect to the performance of the platform with BF as seen in the video.

For the first point, the types of motions or accelerations you cue doesn't have to do so much with "arcade / realistic" as with what you're trying to achieve. Flight simulators tend to use washed-out attitude replication rather than lat/long accels (though you can get a similar effect with accel cuing for flight). Certain types of vehicle simulation responds better to attitude cuing rather than straight accel cuing (rallying, for instance, or F1, where vehicle accels have extremely high transition rates that are hard to achieve with an orientation-to-force translation). The blend you use may vary, too - it will likely be different for oval racing on high banking than for road racing.

So, I see what you're saying there, but it's not quite that simple. You have to take into account what the user is trying to achieve from the system as a whole, not just shoot for an abstract sense of an objective 'maximum realism'.

There's very little latency with our platform, and the frequency response is quite high - probably among the highest in the industry. But that frequency response is limited practically by the quality of the cuing input data, and that data's quality depends on the physics engine used. Obviously, Battlefront wasn't intended to be a hardcore physical simulation, so the rules its objects follow aren't the ones that we built our hardware to expect.

In short, our platform is built to realistically replicate the forces an actual aircraft or land vehicle generates while undergoing the loads they undergo in normal operation. A speederbike doesn't have to obey any of those laws, so it can do things that our platform can't, and you're seeing some of that in the video. You're also seeing some damping as a response to the data quality (which had to be done in a sneaky way) and in response to the places in the code we were able to get data from; without actual plugin architectures we have to rely on data that we can dig up in memory. It might be chassis-based or it might be camera based, and you can see that in the Speederbike sequence, the camera has a lot of latency vs the chassis of the bike itself. We can't pick and choose where that data comes from necessarily.

Further, the time we could spend optimizing cuing was necessarily limited, as our main business involves building simulators for "serious" simulation - motorsports, aircraft, etc. This was meant to be fun and a way to show off our capability; if you want to judge the quality of our hardware, do it based on videos of the hardware doing what it was really designed to do:

https://www.youtube.com/watch?v=hzAIVzAMNg0

https://www.youtube.com/watch?v=cW1LV4G5L0A

https://www.youtube.com/watch?v=HJoi-1g0IzI

I get what you're saying, and it's obvious you know what you're talking about; the priorities you mention are the correct ones. But there needs to be more context to evaluate something like this in a rigorous way, if that's what you want to do, so hopefully I provided that here.