"We definitely care about abuse generated by Workers."
That may be the case internally but it's not as evident through support. I base this on their ability to answer security-related questions, diagnose odd behavior, or mitigate problems. FYI, we are paying for your highest tier of support.
"it should be treated as if they were running their bot on any other cloud provider and making requests across the internet."
Part of this is how Site Analytics and WAF analytics represent worker data (or don't). Even though the worker modifies the contents, the IP is passed through as the end-user IP (at least the way we use them). These analytics systems need to do a better job of identifying anything worker or tunnels related. If this were being done through AWS it would be evident. We can use various mechanisms to mitigate this, but I wanted to clarify why abuse through Workers is different for our implementation.
Also, the process to block non-zone workers was undocumented, and it took a couple of weeks for someone to dig it up and only after several trials and errors. Support wasn't sure it would work, and there was no other documentation (at the time).
We have yet to get an answer about the high volume of tunnel requests from specific goes.
Combine this with the opaque stack you have that causes odd situations. For example, I added a worker that automatically retries 500 errors from the origin. Simple enough. This breaks Zero Trust, though, and causes a redirect loop. There may be documentation somewhere, but there isn't a good breakdown of how Zero Trust fits into a customer-defined worker, and a redirect loop is undoubtedly a poor failure mode.
There is a world of difference between the information you have and may provide as the Technical Lead of Workers, and what I'm getting via support or raw documentation.
I could provide you more information offline if you want.
Edit: Let me just add the other recent thread [1] regarding redirect loops in verification is par for the course. We had the same issue and tried for weeks for progress or resolution. The issue was never resolved, nor could we get information on why the failure mode was so poor, etc. That ambivalence adds up to expecting general ambivalence or inability to make meaningful progress. At some point, you say to yourself, "Why waste my time talking to support and putting in much effort and getting the run-around."