Most big-name studios like Paradox Interactive obviously won’t sharing their trade secrets on the internet, and Youtubers and indie devs usually don’t venture into this niche of games. Thus, finding information on the proper development of maps, grids and various tile-based systems is pretty hard to come by. However, by going on Youtube deep dives and finding several infrequently visited forums online, I was able to sketch out my plan for a proper system:

1. First, the concept of tiles must go from AoS to SoA. While harder to work with, this setup offers incredibly valuable performance. This is because most of the time, game computations need only 1 subsect of data from the tile, (say, the victory point value of each to calculate if you are winning) and dragging the whole tile struct along from RAM to CPU is wasteful. Thus, I will have arrays that I index into with the tile number, such as victory points, buildings on the tile, etc., and not one array of tile structs with those properties. 
2. Separate immutable data (this tile is a hill, this tile is next to these tiles) from meta data that changes during gameplay (there is a factory on this tile, there is a unit on this tile).  This simplifies authoring from many fields to just a few, allows for smaller save files, and moves immutable data to another place to allow parallel work. This also makes for smaller save files.
3. Automate the “boring” concepts like tile existence and tile adjacency by using a texture reader, and present a simplified edit view with QoL features by making a custom Unity editor window. Actually seeing, clicking on, and highlighting tiles of a map and changing their metadata fields is leagues better than editing a CSV file and hoping it looks right when loaded. Additionally, because my custom editor window uses reflection, future users of the tool only have to change a single script to give tiles the features they want. The tedious process of setting up editor scripts is done once and done right.