Detecting a mobile browser vs regular won't handle this well for laptop touchscreen users... especially for anyone using a laptop in a tablet mode. I suspect the larger targets would also help some regular keyboard + mouse users with poor fine motor control.
For tablets we optimise for touch, but I also make sure keyboard and mouse work (e.g. I am extremely careful to support click events, not just touch events). I can do this because we have our own framework (when I developed our product, other frameworks simply did not work well with corner cases). Writing our own framework means I am very familiar with the various quirks and workarounds.
However, browsers force us to make compromises, because we simply can't detect or fix certain problems that affect the UI.
For touch, extra spacing is needed around click targets (allow for fat fingers).
For some touch data entry, you need to allow for different input methods, because accessing symbols and numbers is different from a real keyboard versus a virtual keyboard. Also a virtual keyboard: covers some of the page, causes scroll, causes resize, can cause zoom, loses fixed headers. Avoiding the effects of those issues often requires some compromises.
For touch, you must register onclick events on a div near to an input that can be tapped. Otherwise the browser resizes the touch zone to be bigger than the actual input, and you can't tap the div.
There are many many subtleties to how browsers treat touch events and virtual keyboards