The problem with porting gui libs to Linux is - what is "Linux GUI"? Likely you would want to port it to either Qt or GTK; other routes might be a bigger lift.
Fwiw, React Native for Windows targets WinUI & for macOS targets UIKit (though Microsoft's work here builds a lot on Facebook's work targeting iOS).
I personally don't think this is "the problem". Every platform has more than one UI library: on macOS you have AppKit, UIKit and SwiftUI. Windows seems like the worst offender with WinUI, WinForms, WPF, Blazor, .NET MAUI, etc [1].
I do think it's just a incentive issue. Supporting a platform on React Native takes plenty of effort, so without a big app as both the motivation and test-bed figuring this out there's little reason to invest in it.
Every platform has more than one UI library but there's two (closely related) fundamental differences:
1) there's typically just one canonically recommended for a given use case at a given time
2) they tend to a better job interoperating with one another & conforming to a consistent desktop paradigm than popular Linux equivalents (see e.g. running qt apps under gnome)
This is all largely because they come from singular entities - achieving the above would require more effort & coordination from Linux folk (though KDE do a decent attempt - Gnome has a lot to answer for here).
A TUI target for React-Native would be nice, but Ink gets pretty close (it builds on Facebook's Yoga lib to provide React terminal components - it's not a full "menu/window/view managing" type TUI lib but Yoga is the CSS Flexbox re-implementation behind React-Native, so building a layout is pretty straightforward).
The problem with porting gui libs to Linux is - what is "Linux GUI"? Likely you would want to port it to either Qt or GTK; other routes might be a bigger lift.
Fwiw, React Native for Windows targets WinUI & for macOS targets UIKit (though Microsoft's work here builds a lot on Facebook's work targeting iOS).