I have learned a few things.
The CodeLLDB marketplace page states, concerning Windows support:
DWARF debug info format recommended, limited support for MS PDB.
I thought that perhaps it's better to go with Microsoft tools on Windows, based on the assumption that it would handle PDB better/properly.
How would one go about using the same launch.json for Linux, macOS and Windows? Well, it turns out one can create platform-specific blocks in the config:
"foo": "hello",
"windows": {
"foo": "world"
}
This would (presumably) cause "foo" to expand to "world" on Windows, and "hello" on other platforms.
How would one switch debuggers? Easy, just set a default debugger type and override it for non-CodeLLDB platforms:
"type": "lldb",
"windows": {
"type": "cppvsdbg"
}
Snag: type is special, and can't be overridden. 
It seems like it's possible to set the type in the user's global config instead. So perhaps one should simply wipe the type from the launch.json and force the user to configure it globally instead. Though I don't like having to force developers to make global configuration changes which might affect other projects..
Another slightly annoying issue with using the "Microsoft C/C++" plugin instead of "CodeLLDB" is that the latter seems to be aware of that .rs is code, while the former (for natural reasons?) doesn't. This means that when CodeLLDB is installed you can set breakpoints in Rust code, while with Microsoft C/C++ you need to change a configuration option in VSCode which allows you to sprinkle breakpoints in any kind of file. 
I don't actually use Visual Studio Code myself, but I need to support our developers that do, which is why I'm on this adventure. I don't know what CodeLLDB having "limited" support for PDB actually means, but I don't want the other developers to run into weird debugging limitations down the road. But at this point I'd say that for multiplatform Rust projects it's simply much better to use CodeLLDB on Windows as well -- it seems to be much less hassle.
Hopefully the "limited PDB support" won't rear its ugly head for our developers. With the few limited tests I have done it seems to work just fine. Anyone know where one might run into limitations?