I can only speak for myself, but I think there is a lot of value in supporting protocols more broadly. The basic idea is that simple ad-hoc conformances should not have to pay a high syntactic burden. I think this is relevant beyond protocols that are specifically designed to be function-like. We shouldn't have to choose between semantic clarity in the name of the requirement defined by a protocol and its compatibility with lightweight, ad-hoc conformances.
If the proposal as-written is too cloudy, perhaps we could consider an opt-in attribute that can be applied to protocol requirements to make them compatible with the single-requirement body syntax. This would narrow the scope that both programmers and the compiler would have to consider without requiring everything to be called callAsFunction in order to be compatible with the sugar.
The primary downside of that approach is that it couldn't be retroactively applied to a protocol. I think that's probably something we could live with, especially if it could be added to a protocol requirement in a future release without breaking ABI-compatibility.