I have to point out that this the opposite of how it would actually work.
If the netcode is an issue, it would not effect everyone equally, at all. It would have a smaller impact on players with good local networks, a large playerbase within the region-lock (or whatever it is) and at least decent, consistent speed.
As players begin to lose one of those advantages, the problem would begin to get worse. As they lost more of those advantages, the problem would begin to become severe.
A player in a region with poor networks, a small playerbase, and low speed would be exposed to nearly every problem with the netcode.
In other words, the evidence supports the fact that the netcode has problems that need to be addressed. If the problem was individual connections/networks, then the it would present similarly across multiple MP games, rather than expressing specific, reproducible symptoms only when DA:I is played.
actually this isn't what the empirical evidence always agrees to. I am in east coast US a high density, large player base (even with the PS3) with robust internet connection. I often go into empty lobbies and often connect with small group of consistent users. Now there seems a preferential matchmaking algorithm perhaps trying to match fast connection with each other? Once in a strange blue moon I get matched with people from South America and Europe. Additionally the throughput issue doesn't guarantee smoother performance once in the game as well.
For the actual runs
The star topology makes sense but we don't know all the elements are actually originating from the host machine.
I would think the host
1. handles actual run
2. syncing timers
3. download from server the run information (loot i.e. gold or item, enemy type and count)
4. handle the spawning
5. runs combat calculations since this has to be synced
6. Uploads the information to the server
Users
1. communicates with the server to load the basic run info
2. retains certain individual run information such as gold count
3. downloads after the run item type (drop)
4. experience/run count/etc. sync to server
For the actual matchmaking
1. PC/Console sends a packet to the server requesting a session (to specific region?)
2. this is the mystery
a. Server maintain a database of PC/Consoles requests (from specific region?)
b. just broadcast the request (to specific region?) acting as a simple man in the middle
c. not be involved at all and the initial step 1 is broadcasted
3. Once a host is found (some PC/console that couldn't find a match) it has a on a flag to accept incoming requests, sends acknowledgement what parameters they used for this is in the netcode
4. Host and user starts predetermine steps for connection, latency, PC/Console type etc.
5. Once the checks are accepted between host and user the joining process begins (at which point the netcode actually would be used and would be the culprit for the hanging in endless joining or typival 3 timeouts and disconnect that explains the endless loop when not connecting during a failed joining process)
6. There should be two timout timers, one for the actual IP process that can cause the disconnect second should be in the netcode should there be incomplete joining of the user to the host (this may not be implemented)
7. Once connected there should be syncing timer parameters (causes of rubberbanding) however this seem to be host to each user individually evident from some users experiencing rubberbanding and not others at a given time.
8. If the host itself experience serious slowdown all users see issues in lag such as the frame rate issues.
ME3MP why it works smoother maybe be due to more server based runs (another wild speculation here), that would provide a database of users, matches and be able to provide a non-regional matchmaking. DAIMP they may have went to much ore of peer model because they though it would be more efficient, less costly since server requirements are reduced, quicker matchmaking, etc. this is obviously a issue
Keep in mind that all of the above are my speculations as I don't really have any information to suggest anything I wrote might be accurate, off-base or etc. This includes how they would go about addressing the issue.
tldr