Thanks for your questions.
It’s important to understand the rationale for frames in the first place, which can do a better job expressing the EIP. Frames are required to support introspection by the protocol. It’s not about supporting multiple calls at the EVM layer. It’s about allowing end users to flexibly define the way their transactions should be handled. The protocol can in turn, use the modes we’re introducing to reason about the transaction and safely bound the resources needed to validate and propagate abstract transactions over p2p.
You can see in the examples, there are actually several types of use cases for this and they don’t always require three frames. We could potentially come up with the top N use cases and design the tx with those specific ones in mind, but IMO it goes against the philosophy of the protocol: expose powerful primitives for there users of the protocol to innovate on top of.
Migrating EOA accounts away from ECDSA entirely requires a new transaction type. Today there are several potential PQ crypto systems that could be used to secure an Ethereum account, but none of them are such clear front runners that we would feel confident enshrining directly into the protocol. Not to mention, entire body of work that AA comprises of, focuses solely on making the validation phase of the transaction user-definable. It’s really the perfect combination. There are several nice things that native AA gives us beyond PQ, including reducing the number of intermediaries required to relay a transaction.