To provide a little additional context, specifically what was happening was we paired up an Intel E810 (traffic generator) against a broadcom p2100G (SUT) using a generic DAC cable, and then like I said in the original commit, packets would not transmit even after the regular readiness checks in DTS had passed (ports are reporting they are started and we have run testpmd start and the testpmd prompt "testpmd>" had entered the output). So, this outcome was a little confusing. I tried to throw in some additional steps (like throw in a bring link down and up via kernel on TG side and via testpmd on SUT side) but that didn't make a difference. I also looked through the DTS verbose logs after having done that and saw that testpmd was reporting link was up on the Broadcom NIC. I briefly thought about swapping out the E810 for a second P2100G so it would be a broadcom to broadcom connection, but I didn't have an extra on hand and if we are going to spend money getting new hardware it should be on the newer devices Broadcom has put out vs this model which has been out for a few years.
Anyhow, without getting into why exactly this is happening with this specific mix of hardware, I think the important thing from my perspective is that DTS should not be fragile to device specific behavior like this since correctness is more important than speed. And, I don't know when this will happen in the future with a different device. A (sort of) arbitrary sleep isn't an ideal addition to DTS in my mind, but given that our existing readiness checks seem correct (but may not be sufficient) this seems like the correct action to me.