ARTICLE AD BOX
Unity is very 50-50 when it comes to documentation. There are some types (classes, enums or whatever else) that are explained pretty good, even with examples, then there are some where you don't just scratch your head or facepalm, but you need a quantum physics degree to "decode".
TLDR: One of the main hints about how UE handles cursors is in the Cursor page:
Supports hardware cursors on macOS, Windows and Linux. Falls back to software cursors on unsupported platforms.
What this means is ForceSoftware is the "safe" code path of "I know this will work for anything". Auto is more of a "if I can use it, I will, if not, just give me what you can" type of thing. If the app has "direct access to OS APIs" (and yes, I am being vague on purpose here), there is a chance you can use a HW cursor, otherwise, you won't (like in browser games running on WebGL or the 15 year old and deprecated flash-like Unity plug-in) or on those where the mouse is not fully natively supported (consoles, TVs, mobile devices, etc.).
As for difference, the hardware cursor is said to be more precise. As it is fully handled by the OS and results in better performance. For most intents and purposes use "Auto", regardless of the game type you're coding. The software cursor is "the old way" of implementing cursors (meaning either on older operating systems or some simulated way on those that don't support it natively).
Some blah blah, if you're curious about tangents: from the above link, we can infer that there are operating systems/platforms that do support HW cursors (obviously desktops, since there is no actual "cursor" on mobile devices which would normally use TouchType, but there might be some restrictions on other platforms like TVs, browsers, etc. since they're "layered" - if you'll accept the term. Of course, Smart TVs and browsers have their own "protection", such as low integrity/jobs/OS namespaces/sandboxing methods (depending on the case) and each environment uses what the API has; this is a very lengthy topic and not really 100% related, but it might shed some light to you as to why the cursor is not "100% accessible" and it's just a "software cursor" and also about how Chrome works to isolate itself. So if you want to know how Chrome isolates itself from a desktop environment, you can read this doozy from a while back. The bottom line is, the more a layer (such as the one where an app has access) is isolated, the less features you get (such as a HW cursor). That is why a UWP game has less feature access (since the OS API is limited) than a fully desktop app/game. Similarly, why an Xbox game can't use the full WINAPI in the background on a Console (cos yes, consoles are sandboxed too in their own way).
