the reason we didn't do this was likely because of the possibility of calling SuperToken.operationXYZ functions via host.batchCall arbitrarily

There's methods giving privileged access to the host contract in various places. Some of them (host itself and agreements) are filtered out in the proposed PR. But there's also SuperToken contracts, SuperApps etc. where the host contract has privileged access, and where such a change may make it possible to maliciously impersonate the host.
Enumerating this cases and blocking them may be possible, but this wouldn't be a robust solution.

A cautious solution would be to create a dedicated invoker contract which does the actual call to arbitrary contracts.
That way we don't need to curate a target exclusion list in order to avoid batch operations doing illegitimate calls to methods.

Alongside an operation type which provides a ctx (such that the consuming method can extract the abstracted msgSender), we can then also add an operation type omitting ctx. This would allow calls to arbitrary contract methods with arbitrary argument list.

In order to keep backwards compatibility, we can't switch the existing APP_ACTION operation to an invoker, because that would break existing SuperApps requiring msg.sender to be the host.
So a solution could look like this:

• leave OPERATION_TYPE_SUPERFLUID_CALL_APP_ACTION as is
• add OPERATION_TYPE_ANY_CALL: invoked by a helper contract (address provided by host.getAnyCallInvoker()
• add OPERATION_TYPE_ANY_CALL_WITH_CTX: adds a ctx argument, allowing the consumer to use the relayed msgSender and/or to do agreement calls

related: #1500

Superceded by #1895.