We can't answer questions like "how do they do it" because, well, we don't know, and they won't tell us.
We can help you figure out a few things, though.
In software development in general, unless one has prior knowledge, an approach is to build a feature that works, in isolation from the rest of the software as much as possible (i.e. reduce coupling)(for example: what you've just told us--start with loading a small set of data from XML). Then you work on some other features.
Then you analyze what you've done: after using a profiler, is the process of loading the data from XML taking to long? What is taking so long, is it reading from disk, or is it the parsing, or is it creating the associated objects? Is the game designer complaining that they're always messing up XML syntax when editing the XML file and would like a better tool? Is the issue with the XML, or is it with how they interact with it? Would they need a specific tool to read the XML, edit the data, then save the data again as XML?
Then who needs this XML anyway? The clients? The server? Is the XML too verbose to be served to clients?
Now you get the feeling that "something is wrong" with this XML, but unfortunately, you don't know in advance what exactly is wrong, so you can't figure out a solution for a problem that does not exists yet. Fortunately, you've quite isolated the part of your game that loads the data into the game, so you can update that part without affecting too much the rest of the game.
But update it to what?
And this is why we can't tell you how "it's done". Because you don't know what issues you'll be facing.
A thing, for sure: yes, XML is very verbose and is bad with types, and can be long to read from disk and can take time to parse, so games that use a lot of data may have chosen other solutions. Or they may have hidden the complexity of loading XML under a "loading screen, presenting the menu to the player" (in a background thread) or conveniently decided to not load everything.
Other games use approaches like binary data that they could use to directly populate an object, or a database they load internally or from the server.
You need to consider a couple of trade-offs: with a human readable/editable data format, your game designers can start early on to create content; you don't need to write and maintain special tools, giving you, the programmer, more time to write actual game features. If you were to format your data in any other way, you would need to spend more time up-front developing the required tools. And if you decide to change the content creation pipeline mid-way, then you'll need to re-train your content creators, which may annoy them. ("Bla bla bla the old way was so much better bla bla bla I could do X with my Notepad and now I can't with this PoC bla bla bla.")
If you have doubts, I suggest you test early on with the kind of data you'll need to deal with when the game is ready to ship. See how it goes, and find the best solution for the needs you know you have at that point.
If you wish to avoid cheating, then it is clearly impractical to use human-readable solutions like XML (as players could simply edit the XML file to create items with arbitrary properties).
This is roughly irrelevant. Yes, XML is in plain text and easily readable and editable. But in what context do you use this XML? If it is in a multi-player game, the XML used on the client will only be used to display text and information on the client, like in any multi-player game, it should not be used to do any logic, as this is the server's job. If it is in a single-player game, then why do you care? Players who paid for their game copy will not ruin anyone else's experience; I heard some call this "modding" and have embraced it ;)
You could add a layer of complexity between the player and your game data (e.g. turning your XML data into some kind of binary data), but ultimately, your players are collectively very smart and curious and will find a way to decrypt/modify game data (and they have a lot of time to spend on this), so they'll figure a way to edit this data anyway.
I'm sorry I could not offer a definitive answer, I still hope it will help you a little.
