As you can see, the final outcome is exactly the same. Fees are identical, amounts are identical, but the batched transaction will take less space, than non-batched two transactions, just because in the first case, you have to store Bob's data on-chain, but in the second case, Bob can just keep a proof locally, but nobody else needs that proof.
Then, instead of having weight of 560 bytes + 561 bytes = 1121 bytes, you have a single weight of 685 bytes.
You don't have to remove all data right away. You can use a similar strategy, as pruned nodes, and for example keep the full data, from the last 288 blocks. But: in the long-term scenario, you can remove in-the-middle proofs, because they are not needed for Initial Blockchain Download.
SPV proofs are not needed, to make sure, that the system is honest. They are needed only to show, who was inside. All signatures are valid in both versions: batched and non-batched. You need a valid ECDSA signature, to move any coins anywhere, no matter what.
Very well. Good job.
However, it means that the first transaction is not recorded on the blockchain before Bob submits the second transaction. It means the first transaction should stay unconfirmed in the mempool for some time and miners should be restricted from including it into the blockchain. While this transaction is unconfined, Bob is vulnerable to double spend attacks. In this setting, Bob has to trust Alice.
Bitcoin is already criticised for having long transaction confirmation time. In this scheme, first tx get confirmed long time after it was signed by Alice. I saw businesses which try to join multiple transactions into a single one. However, it is inconvenient for their clients.