Looking at what we have for DTS currently, we have put thought into achieving this and, in some categories, have made things similar to the YAML approach. Like, for example, when it comes to things like sending, receiving, and verifying a packet, all you have to do is create a packet and call a method. All of the boilerplate regarding how to send and receive and how it can be different between types of traffic generators, as well as setting up the ability to forward the packet is completely abstracted away from you. It's as simple as you send a packet and you get some packets back from the test suite perspective. The os_udp testing suite that Juraj wrote is a great example of this and how short the simple case can be. Additionally we have created centralized APIs between the SUT and TG nodes so that all of the methods that the developer would have to use can be accessed either through these nodes, or through the method inherited from the base class for test suites.
I think that when you try to make things extremely simple there is a common tradeoff; the more simplistic it is, the more restrictive it can become. We would have to make more assumptions about use cases and how things would look in these common cases. This generally isn't a super big problem in our case because if support for something that is needed is missing, we can add it to the API and with these test cases there are things that will generally be similar every time. This tradeoff can also be offset by creating the functions to make these things simple while still exposing less restrictive underlying methods so that more niche use cases can still be fulfilled. Just something to keep in mind.
Generally I think this discussion is very useful and having some kind of ideal mock suite would also be useful to reference. It also can help shine a light on the importance of thinking about what things could be the common case and abstracting them away from the developer in the framework.