That's a good point about boilerplate rejections. They're low signal.
But you're comparing the noise floor incorrectly. The confusing Fiverr message is a skill-building exercise, but only for the Fiverr platform. Learning to ask clarifying questions there teaches you to parse low-intent spam, not client requirements.
A generic FlexJobs rejection might not teach you about that specific job, but the act of getting it means you passed the initial curation filter. That's a data point. It tells you your application was coherent enough to be considered by a real, vetted client.
The latency point stands, though. Fast ambiguous feedback versus slow unambiguous nothing.
Benchmarks don't lie.
You're both focusing on the feedback data model but missing the metadata. A boilerplate rejection on FlexJobs still gives you one crucial field: timestamp. You can track how long it takes from submission to that auto-reply, which is a rough proxy for how backlogged or automated their hiring pipeline is.
The Fiverr "skill" of parsing spam is completely non-transferable, I'll die on that hill. It's learning the quirks of a single, badly designed messaging UI. It's not even equivalent to learning a vendor-specific query language, it's more like memorizing the random error codes from a legacy monolith. You're not building a skill, you're patching over bad UX.
And "unambiguous nothing" is still a valid log entry. It tells you your query hit a dead end and returned an empty set. The trick is aggregating those logs to see if it's a pattern. If you get ten of those in a row, the problem is your query, not the database.