Is a code discussion drifting here? I don't think so.
Look at Civ V map script code and compare it with Civ IV from a software engineering perspective.
It's strictly worse.
IV was designed to handle input from xml and scripts, clearly separating data (xml) and algorithms, making the algorithms data-driven and able to cope with vastly different amounts of data. Civ V put everything in hte same lua basket, therefore making it impossible to tune data without changing the program itself, impossible to add resources that a thirs party map script could place on the map, thereby severly harming modding capabilities.
The problem here comes bad architecture, changing something that worked well for no reason (the same result coudl have ben achieved with IV'scripts' architecture, only better). You can even read Sirian's comments in the code where he apologises and tries to defend the new approach, but he didn't decide what was put in xml files.
Here we had a coder/game designer who thought the game had to be played one way, and implemented it in an inferior, closed way, that actually hurt people who wanted to play it differently. In the same way, Civ IV world editor could be used in-game. That ment that you could box your enemies or you own civ for centuries, let barbarians thrive in open lands but unable to reach anyone, and suddenly you could breach the peak ranges you ahd built in-game and have interaction between previously isolated civs. This allowed for a lot of sandbox and creativity.
Civ V decided to use an external world editor, which was great for people who created maps, but whichhurt those who created map scripts, and which totally killed the sandbox capability I just described. The result was, again, a choice in software architecture which led to a poorer game.
Software engineering is 99% design. If you don't know that, don't program. The average productivity of professional, mature soiftware written in C++ is 30 (thirty) linesof code per DAY. This is IBM research, and I confirmed it on various large-scale projects.
If you give any coder a well-defined task to do in C++, they will likely get hundreds of linesof code in one day. But the software engineer work is about finding how to do things, and search skills, analysis skills, are very much required and require intelligence. Problems have been solved, yes, but maybe not in your language, not in a way you can reuse. Basic algorithms (sorting...) can be found in libraries. Basic structures sometimes can't (lru...) so even when you find some code, you have to check it, then if you're performance-driven, you have to measure it. (Is an lru even needed? What is the size? Is it going to be faster than using a stupid list and checking each element? What is the size at which a bigger structure becomes relevant? In my domain, what is the most common size? Should I cater for most common case or for worst case?)
What we got with the map code was an example of a programmer that wanted the simplest implementation for him, his own use cases, without looking at what people could do with it.
The set of choices proposed, of strategies available, is becoming more limited. OCC was invented by chance because civ 1 & 2 allowed it if you played a certain way. Finding new, creative ways of playing the game has become much more difficult with Civ V, because verything has become constrained, developpers are trying to bake strategies for you before the game is even out (play France for culture, play Scythia for war, don't complain if your idea of one civ is different from the developpers, you just won't be able to play it that way unless you mod the game).