Even this, what you are saying about "virtual arms", has been tried. Inverse-kinematic self-avatars were a big thing within the industry about 5 years ago. And it was... largely not that important. Without a tracking point for the elbow, it's nearly impossible to do IK for limbs. Remember, a double-pendulum is a chaotic system. A small perturbance can lead to dramatic divergence between simulated and actual state in chaotic systems.

That said, it's still possible to get body sense in VR, for the head, main torso, arms, and especially hands. It's hard to do. And when things are hard like this, there are economics of scale to consider. For example, the Quest 2 has native hand tracking built in, but not a lot of other VR systems do, and the ones that do often have dramatically different APIs (though OpenXR helps a lot here, which shifts the problem to whether or not the system in question has an OpenXR-compliant driver). Do you go all in on one platform and support its input modalities to the maximum degree? Or do you try to target the common denominator between a broader swath of the market.

Non-VR consumer software developers get to develop their software in an environment of operating systems that have well-established UI and UX metaphors. You make a button in WxWidgets or UWP or SwiftUI or HTML and that button comes with a LOT of functionality that you don't have to program yourself. We don't have that in VR. To make a button in a game engine for a VR game you basically have to implement that entire thing yourself. Oh, the game engine probably gives you a raycaster to be able to find objects, but you have to program up where that raycaster should be firing, which objects you should be interested in, and what interactions hitting the buttons on your controller map to how the button in the view reacts. To a large degree, every VR developer has to reinvent the world when they make something. We're working on the very edge of performance that these systems can eke out.

We don't have shared UI metaphors, but not for lack of trying. There are several projects underway attempting to do just that. MRTK and StereoKit in particular have put a lot of work into just that. But they aren't for everyone. They can't do everything. It'd be like expecting Call of Duty to be implemented strictly in Win32 controls. And the input modalities are so much more diverse and non-standardized than desktop mouse-and-keyboard that I doubt there will ever be a one-size-fits-all UI toolkit for VR.

I reassert that you are not being fair to the VR industry. Everything you have talked about so far has been tried and either found to not be worth the complexity or not possible to do within the current constraints.