Why won't you update to modern versions?

@AstroTibs Why do you personally prefer 1.7 over other Minecraft versions? Why aren't you updating your mod to [modern version]?

The reason I prefer playing that version is that I actually don't: I would like to have access to Elytra and shields and the new combat system and End Cities and Mansions and Illagers. However, some of my favorite mods (e.g. EnviroMine and Smart Moving) never went past 1.7.10, and I would rather keep the latter than gain the former.

The reason I prefer modding that version is that it's just easier. I'm now going to write a few things that spring to mind:

1.7 has an automatic block and item ID assignment, which saves you from having to manually assign block IDs like in 1.6, thus preventing messy conflicts. 1.7 also has a much nicer world generation and biome/tree set than 1.6. Event assignment also seems to be easier, as does its config system.
I don't know anything before 1.6 because I can't even set up a mod environment. I started playing at 1.7.10 anyway, so it's not even sentimental to me.

1.8  introduces BlockPos to replace x, y, z and which can do cool things like pos.up() to reference something at y+1, but it requires creation of many new BlockPos objects which clutters the code and I imagine bogs down computation.
1.8 also rejects the idea of block and meta as arguments in favor of a new IBlockState system which, in principle, makes things more compact by rolling both values into one data type, but if you want to get meta from a blockstate you have to do blockstate.getBlock().getMetaFromState(blockstate) which again makes the code more bulky and probably less efficient.
Lastly, 1.8 introduces the concept of model and blockstate and model jsons, which REQUIRES every single item to have one json file to define how it's rendered in-game and every block to have three jsons to define how it's rendered in-inventory and in the world, and how meta or other variations on a block are inter-referenced. As Delirus likes to point out: "I think it's crazy I need to tell the game what a stairs block looks like. I should just be able to reference internal stairs."
Again, I see why they did it: so that resourcepacks can now in theory change shapes and sizes of blocks and items... but it is so insanely inefficient and annoying to modders that I bet this is the single reason many modders didn't bother jumping to 1.8. Harvestcraft famously screwed up their model jsons in their final release for 1.8 and Village Names had to include overwrites to make things render. Plus, you now have to register "bake-ins" of block and item variations based on this new json system.
All these things taken together is why 1.7→1.8 is, for me, the most difficult phase.

1.9 Changes their sound registration system which can be a pain in the ass if you're not prepared for it, and they also introduce subtitles, which is noble, but it's just another thing that you have to consider doing, which would add to the workload.
Rather unique to Village Names is the fact that vanilla introduced bugs and features that make village generation more annoying: servers now reset player reputation to 0 in all villages on server reset, which interferes with VN's codex commission system (a vanilla bug NOBODY NOTICED for years until I did), and the new meta-rotation system for village structure generation always throws a wrench in for block rotations in different buildings by attempting to standardize rotation values.
Also, I discovered that sound getVolume and getPitch in sound events now return null and that's never been fixed, forcing me to re-calculate note pitches from scratch for ASMC. That wasn't so bad to me because I already understood music physics or theory or what-have-you and the logarithmic note system... but imagine if a modder didn't?

1.10 gives me no issues. It's so similar to 1.9 in its code that I once literally pasted in 1.9 code while porting a mod and had zero errors in my IDE. 1.9→1.10 is my favorite time.

1.11 is almost as good as 1.10 in this regard. Very close to no problems. All entities are their own classes now, like ElderGuardian and ZombieVillager, so some care has to be taken with that.

1.12 should have—in fact used to be as painless of a transition, but at some point Forge changed the everything-registration to some different system, so I had to re-do a lot of it. They also decided to make the function that returns the string name of a biome client-only, which caused me some hell. And they re-named many functions without changing what they even do, but aside from that headache it's not all that bad. OH, and you have to take extra care when registering spawn eggs or else they wind up in EVERY creative tab.
Also, VERY important to mods that utilize it: the new Advancements system is substantially different from and more complicated than the old Achievement system. You have to write your own advancement trigger listener system, as well, which feels like Forge just left that part out. And it uses extra-fickle json files.
Now, my 1.10–1.12 notes may be comparatively minor, but bear in mind that that the two biggest legacy versions to mod for are 1.7 and 1.12. So anyone who wants to go from one to the other has to deal with ALL OF THESE ISSUES LISTED in aggregate. You can see why a lot of people tear their hair out when porting.

Lastly, the 1.13 Forge code base was so significantly different that I didn't even know where to start porting Village Names. Forge attempted to write a point-by-point conversion document, but when it came to WorldSaveData, something integral to Village Names, they essentially said "we hope you don't need to mod this." Just figuring out how to find villages when they generate so that I could add signs was beyond my patience. So I stopped there. None of my mods are going past 1.12.
Years ago when 1.13 Forge was released, I noted this code base problem on Twitter and said that 1.12 will be the next 1.7. And I was right: https://twitter.com/AstroTibs/status/1098134076937113600