* Malleability could be fixed by just skipping the signatures (the same data that SegWit would segregate) when computing the txid.
That _is_ segregation of the signatures up to completely non-normative ordering of data transferred. Segwit could just as well order the data into the same place in the serialized transactions when sending them, but its cleaner to not do so.
On the contrary, rearranging the data in transactions and blocks is an unnecessary and ugly hack to get that effect. It means hundreds of lines of new code scattered all over the place, in the Core source and wallets, rather than a few lines in one library routine that everybody else can copy.
* GREATER bandwidth savings could be obtained by providing API/RPC calls that simple clients can use to fetch the data that they need from full nodes, sans the signatures etc. This enhancement would not even be a soft fork, and would let simple clients save bandwidth even when fetching legacy (non-SegWit) blocks and transactions.
This would be no greater and it would have _no_ security at all. The clients would be _utterly_ beholden to the third party randomly selected servers to tell them correct information
If a client fetches a block without signatures, with SegWit or not, he cannot check whether the transactions contained in it were properly signed. With SegWit, he can check the hash of the non-signature data; but if he is an old client, he will not even be aware that he is not checking the signatures.
With the special call solution, if the client wants to validate a particular block, he asks for it in full, and then he can validate everything (except the parent link), as now. The extra call can be implemented with no fork, so clients who do not upgrade, or do not wish to use that special call, will still be able to verify everything as they do now.
In other words, soft-forked SegWit *forces* old clients to fetch only part of the data, and limits them to verify only that part, *without them being aware of it*. The special call solution lets clients decide case by case whether they want to verify a block or trust the node (that they are already trusting to some extent); and it does not change the behavior or security of existing client software.
The savings would be greater because clients who choose to use this call for old blocks would get fewer data, whereas with soft-forked SegWit everybody would have to fetch old blocks in full, signatures included.