That way the core authors don't need to know a thing about how the parent program (usually Retroarch, but it doesn't have to be) handles input re-mapping, and y

That way the core authors don't need to know a thing about how the parent program (usually Retroarch, but it doesn't have to be) handles input re-mapping, and you can change all of them in one place—or use multiple for different cores, or even set it on a game-by-game basis, RA supports all that, too, and the cores don't have to care about it. It's less complex than a wrapper program having to know a bunch of different config formats and conventions. Again, cores run as shared libraries inside Retroarch. These "fake inputs" aren't, like, actual OS-level simulated devices. It's more like a core listens for events of type (name made up) "ra_analog_0" and treats anything coming in as left-stick x-axis positive-direction input, and by convention so do most or all other cores that emulate a system with a left analog stick (or perhaps with just one), unless they have a good reason not to, so default Retroarch-provided automatic input device mapping can make most common gamepads do something sensible with most cores, as soon as you connect them. Then if you prefer to swap left and right sticks, you do it one place and it works everywhere. Or if you prefer to swap left and right on just one game, you do that. The core never has to know about any of it.