The first three questions are actually more or less one and same, just being different perspectives on it. The answer to it is as follows.
Lutris is a system for managing owned/playable videogames. That is to say, the primary purpose of it is to provide the user with a single interface for running all games he has installed on the system. It allows you to create links inside of it to run those games; some games have a common subsystem that is used to run them (such as an emulator, or Wine – which by its own name Is Not an Emulator 
), and as it makes sense to configure such things once ever rather than separately for every single game, the configs for these subsystems have been separated from the game configs and named runners (they included the path to subsystem binary and configurable options for it, and allowed to override specific options for a specific game). For sake of configuration clarity, game links are grouped per runner, so that it’s easier to tell what kind of configuration the game link has.
That being said, users like their systems being easy-to-use, so some quality-of-life features were added on top of that. First, since many games (most of which inevitably require Wine) have some issues that have to be dealt with before you can play them on a modern Linux system (such as installing a patch, or fiddling with environment settings), there were install scripts added; they described the installation process which Lutris reproduced, and required minimum input from user, such as choosing where to install the game (which is available for all games except those for which runner itself controls the location), inserting game CD or finding the downloaded installer file. Second, since not all systems have an easy way to install this or that package, every runner got an option to download a prebuilt version of the platform (presumably packaged Windows-style, with all but most base-system level dependencies included); for Wine, this includes multiple Wine versions which some games might require. And third, this was extended to certain online game sources as well, with obvious support for the most popular ones like Steam and GOG (being able to download the game automatically instead of requesting the installer in case of GOG, or just using the installation API in case of Steam).
Thus, here’s the order of things. Lutris is used for accessing your games (using a bunch of configs) and game subsystems (named runners and using configs of their own); for sake of convenience, this got extended to being able to download prebuilt runners instead of installing them by hand/in package manager (with the runner location obviously being set to the folder with that downloaded subsystem; Steam is proprietary so of course it can’t really be controlled like that), and automating the game installation/configuration with community-written install scripts (for sake of one-click installs that spell user-friendliness). Everything else is either a direct consequence of that, or is circumstantional and based on factors external to Lutris itself (e.g. Steam client specifics).
In case of Steam, I configured the install paths in its settings; in other cases, I have control over where it can be installed. All runners besides Steam can be installed in multiple instances but why would you? Just use the one which works (Wine is an exception but it’s more of a per-game compatibility matter). And regardless of whether it’s a game or a subsystem, if it can be installed in package manager, it usually means not needing extra fiddling with settings (as games that can’t be run normally wouldn’t be in stable package tree), as well as actual version management (which Lutris does not really provide as most games and subsystems tend to have only states of “it works” and “it’s broken”). On the other hand, if you can’t be bothered to install a hundred packages for a single game, prebuilt version comes with all necessary dependencies so that’s also a valid option… As for the games, I prefer installing and setting them up by hand (and then just adding them to Lutris manually), but that may be because more often than not the game I’m installing is somewhat obscure and no one made a script for it yet (or even added the game) in the first place.
As for your last question, in most cases you’re either expected to have an idea what you’re dealing with, or it’s the same for all games with the same runner (not counting Native, which is a no-runner group really). Either way, if such information is important, it can be – and often is – added in installer description (which is visible in the installer list under its name); but keep in mind that installer scripts are community-made, so the control over that is rather limited. As for the games filter, there actually is one, I believe; that is, for the game to be automatically downloaded, it’s pretty much guaranteed to be free (unless it’s a game that you pay for after you finished installing it), and there’s specifically filters for both free and opensource games (with subtypes).