Haiku already has its own third-party 'native apps' that directly use its APIs and also promotes them in HaikuDepot [0]. Users from other OSes will always ask for other apps and if the OS has a 'modern browser' even when WebPositive is based on the same technology as Safari. i.e, WebKit. But they'll still ask for Firefox and Chrome.
The fragmentation argument can be made from a maintenance point of view. For typical platform support, it's easier to maintain and target one OS that has a single unified stack and SDKs (GUI toolkit, sound, input APIs, etc) than to do this on multiple distros and to only officially support 5 Linux distros, which is why Windows and Mac are always targeted easily. There is no 'standard' SDK on Linux distros, which is why one user could be using ALSA or OSS, X11, XWayland or pure Wayland with Sway, etc. Haiku has first-party default system components which it maintains.
It also sits in middle of macOS and Linux, being that its open-source like Linux and has a standard defaults and a SDK like macOS. So maintenance-wise, maintaining one of each OS like macOS or Windows sounds less expensive than targeting 3 separate distros here.
Second, what you point out about having its own third party apps is correct and i know about what Haiku is - i even did some quick port of my older 3D game engine some years ago [0] for fun.
But none of that answer the question you quoted. What you are writing is from the perspective of a programmer who may want to target Haiku or works on Haiku. My question is from the perspective of a user.
As a programmer i'd target Haiku out of fun since there is no practical reason to target it. As a user i'd also use Haiku for fun since it has too many limitations to have any practical use (except perhaps if all your work can be done via the console and you connect with ssh to some remote Linux server to do your work).
But if you are not using it for any practical use (since for that you'd use Windows or Linux), why bother with anything else than the native APIs for your desktop applications on a desktop focused operating system where applications are meant to integrate with the system itself?
I have to agree with this. Although, if Haiku met a few more of my personal criteria for what I'd like in a Desktop OS I would be willing to sacrifice a good deal of practicality to use it. For some, that threshold may already be met.
When i hear about fragmentation i think about incompatibilities, like -e.g.- the home computer fragmentation of the 80s or the Java ME fragmentation of the 2000s. However there are very few incompatibilities between modern Linux distributions and you can avoid them when you are releasing software.
And yes, macOS users probably also tell you that they prefer macOS, though note that they also are often very loud about preferring software that takes advantage of their OS' features because this is why they use that OS.
The thing is, macOS has a much richer selection of software than Haiku has (and most likely, ever have) so macOS users at least can fall back to those. But if all you are going to use on Haiku is ported software that ignores native APIs then what is the point of using an OS with less hardware support and features?
The Linux desktop being fragmented doesn't mean much - your Qt application ported to Haiku will also work on KDE perfectly fine and chances are even if you limit your software selection to Qt-only applications, you'll still have more applications to work with. Though that fragmentation is really a poor description since there are standards you can rely on, like X11 - sure someone might be using Gnome or XFCE or Window Maker or i3 or whatever as their desktop, but applications do not target those environments, they target a lower level of the stack that is shared among these and making an application on XFCE doesn't mean it'll only run under XFCE.
So yeah, it might look fragmented, but unless you are some custom support worker that tries to navigate someone through the UI via phone, that isn't much of an issue in practice (and "in practice" is the important bit here because the reasons i've seen people put forth for having Qt/Java applications ported to Haiku and ignore Haiku's own APIs are all about practicality - which ignores the elephant in the room which is that if you care about practicality using Haiku in the first place wouldn't be a good choice anyway).