Hi @orlet thanks for your response, it's really helpful.
Below RCL 8 -- getting to RCL8. At RCL8 -- getting more rooms to RCL8.
Nice and simple! Perhaps it's best just to take this attitude and work through each obstacle as it presents itself rather than over thinking it without much experience. And I could definitely see myself pushing remotes way way down the list, so thanks for the insight there.
Personally, I try not to study the code of others too much. Instead, I normally talk to the people on the slack (highly recommend joining if you haven't yet) to get higher end concepts and ideas on how they do things, then adapting and implementing them myself as appropriate. Also observing other's code out in the wild. Some interesting observations can be made that way.
Reading codebases is not really my first preference either. Partly because in the case of screeps it kinda kills my ambition to see the level that those bots are at. And also it's just more fun to mess around, experiment and come to a solution I can take ownership of. I also much prefer working from more higher level concepts. But I have found reading/understanding other peoples code to be a great way to level up quickly with something new (in all work, not just screeps). Great point about observing peoples bases in the wild.

I would strongly suggest avoiding spawn names and Game.spawns altogether. Use IDs from the start, it will make life much easier for you later.
Spawn names are just confusing and pointless. I personally think they should be removed from the game completely. The tutorial would be more useful if it didn't use them.

I have monkey-patched Creep.move() and Creep.moveTo() methods, first one to save the creep's intended move direction, and second one to inject different defaults (reusePath: 50 and ignoreCreeps: true), as well as use custom CostMatrix callback so I can mark some specific creeps as unwalkable at some specific situations.
Then after all the creep logic has run its course I run another loop of collision resolver, that checks if there's a creep in the creep's intended move direction, whether it is moving or not, and tries to move the blocker creep out of the way, with some role-specific overrides provided, too.
Took me a few hours to code, a couple of days to iron all the edge cases, but now it works pretty well for 99.8% of cases. The remaining 0.02% result in some weird creep dancing, but tend to resolve themselves in a few ticks on their own.

The most basic (and seemingly common) way to achieve it is to have one creep (typically a healer) constantly moveTo a leader creep (typically a dismantler or attacker).
The most complicated way that I currently have in my code is a 3x3 grid with pre-coded movement patterns. Eg. Turn, swap rank etc.

@donatzor The idea was to make the paths that were found have the same value as roads at least while generating paths. Generating the paths is the easy part it's the making the ones already generated be as helpful as roads when generating new paths that's the hard part.