10Hz few bytes is not a problem. Thats like 1KB (forget minimum packet size). Go with your original idea IF you have a driver/transport layer which works with the ESP32 IDF.
UDP or TCP? Well that depends (again).
If you want all the data (only lose data in unacceptable long term hung scenarios) then a connection based protocol like TCP. But you want a mesh with all processors sharing the data & to do this via TCP based transport would require a discovery mechanism e.g. mDNS or multicast etc.
If you want the data in 'real time' then UDP is best. Actually multicast if you want to share with all the other processors. You need a smart switch for multicast to work.
I would go multicast if you can. You might loose the odd packet (assuming good hardware) but if this is telemetry then that would seem best.
The UDP/TCP difference is similar to that between your bank account and a speedo. You want all your deposits recorded in your bank account but are prepared to wait for a minute or so for that to happen. With a speedo however you don't want to see the speed you were doing 1 minute ago. EDIT: TCP for deposits, UDP for withdraw transactions
You could do both of course.
PS I have used AJAX HTTP (TCP: connect, request, receive, close) to exchange data in a local system and use that data to update a vehicle speed dial @10Hz. Also MQTT QoS0. MQTT is less jerky (its a push model after all) but both are good. ESP AJAX typically runs at around 30-70mS BTW.
I have also used multicast on aviation loggers (e.g. iNET-X) and also connectionless 'real time' radio streams.
Both work well.
However I have used TCP on a poor quality link where the requirement was not to loose data and so one design requirement was to have a sensor side large memory buffer for use when the Ethernet extender was having a sulk. The receiving user interface team just did not get that point and their user graph contained gaps in the data as they ploted using local receive time base rather than source time base. My sensor hardware design proving rig (stimulate device, graph response characteristic) was perfect. Just every now and then the graph scroll would pause whilst waiting for my source to resend etc.
If the link is good either should work but multicast saves you having to discover mesh items.