The framing is right, and I would push it one step further: ambient context is not merely an invisible parameter, it is a parameter removed from the type system's jurisdiction. The compiler can no longer tell a caller they forgot it. That specific guarantee is what is being traded for the convenience, and naming the thing being traded makes the trade defensible rather than just comfortable.

Often it is worth it. The place I would want the article to be most explicit is the boundary where the flow stops being automatic, because that is where invisibility turns from a design choice into a defect: work that hops off the current execution context, fire-and-forget continuations, background services resolved from the root scope, anything handed to a queue and picked up later. In each of those the value reads as default rather than as missing, and a silent default is the failure mode no test written against the happy path will ever catch.

The diagnostic I would add for any ambient value: write down what a default reading MEANS. If the honest answer is "either nobody set it, or the context did not flow", then it cannot carry anything that matters, because those two cases are indistinguishable at the read site.