At those speeds, assuming a single tx takes about 250 bytes, a full node would fill up a 1TB drive in a few days, and new nodes would struggle to ever finish the initial block download...
It's easy to be scalable if you have no concerns for bandwidth and storage requirements...
Not sure why you're saying it's easy to scale, and even if it were, not sure what's wrong with supporting this level of scaling. Our advantage is actually also confirmation times, the scalability is a bonus. The full history being too large for a new node argument basically applies to any scaling on the main protocol at this level. We do have a solution for this, given how we store the state using a persistent Merkle tree, and a full node only needs to store the current state and not all transactions. A full node can check that the history is valid at any time, since consensus is reached on the hash of a round, for which proof can be requested from nodes that have the history at that point.
We expect a new node to sync up by only getting the latest state of all accounts (which is a lot smaller than the transaction history), and checking transactions through random sampling.
If I control a large enough stake, why can't I report valid transactions as conflicting and steal the stake which those lockers held when they signed the transactions?
You have to provide proof of the conflicting transactions, as two locker signatures approving conflicting transactions. It's specified in the paper, this proof is considered in lieu of the signature of the penalized node's account.