Putting game content data in code means that to see any potential change or iteration of that game content data, you have to recompile the game itself. This is bad for two reasons:
Many languages that games are written in have long compile times. C++ is particular can be very bad in this respect, and C++ is a very common language for large commercial games. It is less of an issue with languages like C# and Java, but still not as fast as being able to store game data in external files that can be hot-reloaded while the game is actually running to see changes.
Many games are developed by teams which often consist of non-technical developers (designers and artists) producing content. Not only do non-technical people not want to have to recompile the game, or deal with "cumbersome programmer tools," to iterate on their content, it may be desirable to minimize source code exposure to only the programmers (because the fewer people who have access to source code, the fewer people who can leak it -- accidentally or not).
I think you're overestimating the complexity of loading data from text or XML files. Most of the time you should use a library to do this, which makes the process of parsing the XML/JSON/whatever much easier. Yes, there is a bit of up-front cost to writing a level loading system that is data-driven but it will generally save you a lot of time in the long run versus tons of unique classes to represent each level.
Smaller or simpler games don't have as much to gain from the longer-term investment of a data-driven approach, so unless the developers are using existing frameworks/engines that support it it may be more efficient for them to simply encode the data in the game code.