The games you mentioned pretty much all had different implementations of pathfinding. Which one would you want to be default in construct? They all had different limitations and solutions, there isn't a one size fit all.
Even Starcraft, which came significantly after some of the games you mentioned, used different pathfinding algorithms for certain units only, within the same game.
Here's an example codeofhonor.com/blog/the-starcraft-path-finding-hack
The reason you haven't been able to find a solution for the sprite overlay problem is because even the big name developers couldn't find a solution for it, they just designed around it and hid it well. Case in point, some units like air units and zerglings don't move in formation at all. They just lose collision with each other while moving, and spread out when they get to the destination. A good developer will focus on making a fun game look good, rather than get stuck on a specific requirement like non overlapping units that doesn't matter in the end anyways. See what this guy did - striketactics.net/devblog/starcraft-1-pathfinding-technical-analysis
Here's another great article. tl.net/forum/starcraft-2/132171-the-mechanics-of-sc2-part-1
Note that Starcraft 1 (Brood War) relies extensively on a* pathfinding, which is exactly what Construct gives you. How you implement it is up to you though.
Swarming boids style movement used in Starcraft 2 can also be done using the 8direction behavior in addition to pathfinding. That's another huge topic as well, but that could be a specific thing that I wouldn't mind seeing added as its behavior in Construct. construct3.ideas.aha.io/ideas/C3-I-1680