Indeed. If cross-platform UI toolkits have shown us anything, it's that cross-platform UI toolkits are a bad idea.
You end up targeting the lowest common denominator, and a UI convention that works on Windows won't work on OS X, and vice versa.
One big error made by these toolkits is to base themselves on generic pixel-oriented layouts, instead of more abstract declarative ones. For example, if you need a dialog box with a small form and "OK" and "Cancel" buttons, you'd lay each component out on a form, and the layout would be identical on each platform. But this is such a common thing to do that it would be better to just declare what fields should be visible and what actions should be available, and have different, platform-specific, opinionated adapters that can wire together a native UI from this metadata (together with some platfomr-specific, CSS-like hinting: "on OS X this field needs to be at least 500px wide", etc.).
There's a wide selection of common idioms (dialog boxes, file dialogs, "wizards", preference panes, alerts, etc.) that fit into this scheme. The reason nobody did this is probably because developers overestimate how important it is to micromanage the UI, and don't think a system like this could support all variations that apps need. In truth, most UIs are quite pedestrian, and could benefit from being driven by a high-level description.
This is where React (and React Native) actually would help, because the component interface is separate from the component implementation. You can have a fairly high-level mostly-declarative description of your app that pulls in platform-specific versions of certain UI widgets where it makes sense to have one, but otherwise relies on generic ones.