What pentesters can do, should do, and often do is simply start the test from a workstation that is given to them - you assume a successful social engineering attack as the starting point, and test whether your process and technical controls can properly limit the impact of such a compromise without trying to replicate the actual social engineering step and the associated disruption to the targeted employees.

Taking over that first engineer's workstation shouldn't ever have resulted in $6.3B of damages. I would consider it reasonable if those privileges could be abused (by e.g. the same engineer intentionally) to cause $6.3M of damages and the rest would be mitigated or prevented; so for this incident we could say that 0.1% of the impact was caused by the initial compromise of that workstation and 99.9% of the losses were caused by all the other failures - so it's effective for any pentest to focus on the latter part, ignore the social engineering and phishing part (since you can't really eliminate it anyway - unlike many other flaws) and assume initial compromise as a starting point.