Unfortunately this isn't correct either. I am familiar with that option Loader, and it does make the BoP terrain generation apply to the all world types including 'Default' and 'Large Biomes' ,but not Superflat. If you load up a superflat world you will notice a few things;
-It is always the same biome (Plains)
-There are no BOP plants and/or grass, as BOP's terrain generation is config file and profile based, not injected
-There are grass/flower items generated from other mods that inject terrain generation regardless of configuration (lazy)
...basically because they coded it the right way, it doesn't just inject itself into each world as it is created like for example, Food Plus. It is smarter than that, and it does not affect the SuperFlat terrain generation process.
Superflat uses it's own unique method based on the 3 block types you choose for your land makeup, and is generated using a method all it's own outside of the normal routine (this is why BoP chooses not to touch it). As I said in my previous post, using superflat will give you villages because it does not use BoP as part of it's terrain generation routine, and is an inaccurate way to make comparisons for problem solving BoP terrain generation.
In real world test (not superflat), the BoP terrain generation settings from the config file hold true, and are the problem. They are simply all (but 1) turned off by default. Today I generated a 2000x2000 area with the default settings from unzip, and found 0 villages. I then deleted the region files, and made the adjustments to the config files I mentioned above. The map was physically identical, and I found 5 villages in the first 20 minutes of flying where there were not villages previously (MapWriter comes in handy here).
So, in the end we are back to where we started. The OP correctly identified that for default created worlds, village generation (and further, TC building generation) have been turned off in this modpack intentionally in the config files. I pointed out to him the two places he needs to go to undo this.
My question is why this was done. The issue tracker lists this issue as 'Cant Fix'. Does anyone have any better information about why they made these config file changes to specifically prevent this from happening, and why the devs believe it 'cant be fixed'? As I eluded to before, it may be a problem with maps generated on an older version of AOTB that upgraded to this version, as I haven't been able to reproduce the crash problem when the a map was generated by 1.0.12a.