General answer regarding xml and savegame size: when something related to xml is saved, it is usual the type. However what is actually saved is the index of the type in the xml file, meaning it is just an int. On load, the game reads an int and then it use the xml file in question to figure out what that int mean. Some mods can save the type string instead of int to make savegames resistant to xml changes, but the fundamental principle is the same.
Sometimes cached xml data is saved in vanilla. The cache is of fixed savegame size regardless of xml settings. The issue why I don't like this approach is that it prevents xml changes to affect existing units/cities etc while new ones are affected, causing a weird mix. This can be solved by modding savegame code to recalculate the cache on load, but that's not the topic here.
Since both type references and caches are fixed size regardless of xml setup, it is quite hard to change something in xml, which affects savegame size or performance in saving/loading. The exception is saving arrays, like an array of promotions for a unit. This array will use twice as much disk space if you have twice as many promotions in xml.
This is true for most if not all xml files, including LHs.
Unlike savegame code, I haven't really looked into runtime LH code, but I trust what is already written here, partly due to who said it and partly because it fits what I would predict if I should take a guess.