Responsive Design
A UI is designed to convey information to the user, to make the user's current capabilities clear, and to present them alongside their relevant context. It’s essentially displaying a state, and offering various transformations on that state. An issue arises with wild variations in input methods. On a small touch-screen phone there is limited real estate so information is typically hidden, and any action requires obscuring the only source of information. There is no effective hover state or mouse cursor that can change appearance to represent the possible transformation. This creates a situation where both the state and what you can do to it are hidden from the user. On a desktop using a mouse, your cursor’s current location is always visible, including different states that can reflect the specific capability that will be performed. Those capabilities and states can be expressed both through the cursor itself as well as the targeted element. This means the desktop is capable of conveying a much greater density of information and interaction, while maintaining a consistent sense of what the current state is and how you can modify it.
The conclusion that this leads to is that mobile and desktop interfaces should have separate UIs. That, however, is not the convention.
Why not?
Supposed benefits of responsive design
For most sites the simple answer is the vast majority of their users use mobile devices. If 95% of your users are exclusively using mobile phones, responsive design is a pragmatic approach. Give a mobile-first experience for 95% of your users and rely on responsive design to have something serviceable to the minority. Another benefit is maintenance: one fundamental style with slight variations for mobile and desktop simplifies what you have to keep track of. That simplification pays off across testing, code review, and many of the longer-term costs of the codebase. There are also many odd devices people may use your site on: a tablet or a refrigerator. A responsive UI in theory should allow you to cover these odd exceptions without any additional cost or consideration.
I am not convinced though.
Maintenance
In my experience the maintenance benefits are largely an illusion. Responsive design results in highly complex components that accrue conditions for different styles and use cases over time. In the future when you need to add something exclusively to the mobile view you need to remember the occult meaning of the opaque array of conditionals across mobile and desktop views. These keep piling up until the component is so heavy with complexity that any change is almost guaranteed to cause a regression for some edge-case no one remembers. Keeping desktop and mobile components separate reduces that combinatorial explosion of the different conditions, which can be the difference between a feature shipping smoothly and one needing to be nursed with patches.
Mobile-dominant user base
As for the mobile-majority argument: this one is fair. With all the complexities of design and maintenance factored in, however, keeping them separate may still be faster overall and allow for a better user experience. Having the two views would also give you a lower barrier to providing exclusive mobile or desktop features, as you wouldn’t need to consider how something might be represented in the other view. Desktop’s lower usage may itself be a consequence of the reduction of all capability to what is doable on mobile. If everything is already easier to do on your phone, and the desktop experience is structured for a mobile interface anyway, why should anyone use desktop?
Odd devices
The pooling question, how we distinguish between desktop and mobile users and account for unusual devices, is the hardest part of this. Most of the issues related to this also exist for responsive designs, though responsive does handle the failures better. From my testing I have found that just having a wider minimum on desktop is more than adequate to cover the bulk of the use cases. Build the desktop interface for a fullscreen desktop experience, set the minimum at the width where usability is compromised, then serve a mobile view that expresses that same functionality. The site is still usable on these odd devices when they are wide enough to trigger desktop though there will be some unavoidable friction for the user. Giving users a control to switch views themselves handles it, and for these peculiar devices that's adequate.
Organic isolation
An additional benefit of isolating mobile and desktop views is that it structurally enforces extracting business logic. If you have two components that are largely a reimplementation of the same feature the incentive organically becomes extracting it so the two components can share the logic. This helps to enforce having more isolated and testable business logic, and makes porting features between UIs trivial. It also invites creativity: if the logic is already available to the mobile UI, you may find a way to express it there rather than neglecting it. Mixing mobile and desktop views in one component stacked with conditions means the business logic has complex variations mixed up in the UI, and it's not immediately clear which logic each view actually uses. If you isolate the logic it's quite trivial to see if the mobile view is importing some function or not, and the conditionals for which view consumes which logic are clearly distinguished from the business logic or view UI. The view UI just uses what it will use and the business logic is indifferent to what uses it.
Experimentation
This isolation also allows for quick A/B tests that require changing very little code. Having the desktop business logic at hand means you can experimentally present that state or capability to a mobile user and see its impact. Building your project this way makes such experiments nearly free, with a substantial potential impact that would otherwise be lost.
Desktop-first design
I advocate designing for the desktop first. As a richer interface it allows us to see what sort of capabilities and uses of data are valuable in a much more open form. If you create a desktop interface mindful of what data is possible to show and transform, and only then build out the mobile one, you will notice valuable data and capabilities that would otherwise have been neglected. The interface you build for constrains your relationship to the data and capabilities; by building for the more powerful approach you will see how to express some of that power in a mobile interface that otherwise would be denied to the user. I think my Exposure Guide mobile interface is an excellent example of this. I built it with only the desktop interface in mind and had no conception of the mobile interface until I began work on it. Once I did, I arrived at an interface that allows all the capabilities and data expression from the desktop that had originally appeared intractable on mobile.
On denying the user
Responsive design denies capability to the user up front, and the problem is that the data itself calls for certain capabilities. The user instinctively has some desired relationship to the data and how they wish to transform it. Your unwillingness or inability to allow the user to express this instinct builds a sense of frustration. Users are coming to your project with certain desires and goals. The state you maintain must give them proper affordances to perform the transformations that reach their goals. The denial of this will build in the user a sense that you have wronged them, and they are fundamentally correct. The purpose of the interface is to serve as a medium between the user and the capabilities you offer. Part of that requires seriously coming to terms with what the data in your interface is and how the user can modify it. Doing this is far easier to accomplish in an interface that is not structurally set up to obscure those capabilities. Designing desktop-first will allow you to get a clearer sense of what it actually is that the user will want to do. You shouldn’t obscure your own goal from yourself. Designing mobile-first is designing with a hand in front of your eyes.
LLM-assisted coding
Nowadays, with LLM-assisted coding, things like boilerplate or repeated code are essentially zero-cost to write. If you have highly nested UI logic and conditionals the code is simply more fragile and any change is more likely to cause regressions. Having isolated files with clear logic they use, clear states they represent, and clear conditions under which they are expressed makes testing easier, since you know the exact conditions to validate. The clearer code makes it easier to review the LLM-generated code and to be confident in it. The cost of creating or moving a feature to another component is also trivial. If you write up the business logic and implement it in the mobile UI, then that is a best-case scenario for an LLM to implement it in the other view. Once implemented it's also quick to review and see what it actually did. In the world of LLM-assisted coding, that clarity is worth far more than the deduplication.
Conclusion
The benefits of having two discrete UIs depending on the interface are hard to capture. However, it's beyond question that attempting to find an average that works with both leaves you with, at best, a mediocre result. The state and interactions easily expressible across both are only the shallowest level at which the user can engage with your project. Your project and your users deserve better than that.