In my experience it's much harder to onboard devs to a custom-ish process than it is to hand them a purpose built tool with proper documentation and lots of examples of real-world usage to learn from.
I tend to try to use already made tools over doing it myself* as it makes onboarding easier, lightens my cognitive load, reduces my testing surface, and is generally quicker than coming up with my own solution.
* A bit of a disclaimer... I mean well made, well tested, and well supported tools taking into account the time cost of doing it myself, the complexity of the tool, how important/ingrained it will be in my application, the number of contributors in the project, the test coverage of the project, the speed/ease it can be switched out, how well it actually solves my problem at hand, and a ton of other things. I do not mean that you should blindly use every tools you can whenever possible, or that you should use it because Facebook/Google/Other-Company uses it.
Enzyme isn't necessarily one of those, like I said I haven't used it, but I also haven't found a need to. Some abstractions over TestUtils' event simulation would certainly be valuable.
What I am trying to present here are patterns of different testing scenarios in a format that should be useful regardless of the testing tools you may be using.
All IMO but I def think you should at least check it out.
Also the DOM api is actually pretty simple to use when it comes to traversing the DOM. No need for "jQuery mimicking." Keep it simple.