This is what the current block size debate is about and has been for more than a year now. I'll try not to repeat all of that here.
Your numbers seem roughly correct. Whether 600MB blocks are possible in your side chain depends on how your side chain would work. If you get rid of the Proof-of-Work security and it's all data center grade hardware and bandwidth between parties that trust each other to some degree, then there is no problem. It would probably make sense to lower the block time in that case too, for example 60MB every 1 minute. In fact, blocks probably wouldn't make sense at all anymore, why not just an append-only database of single transactions with some checksums for security?
Sidechains can trade some properties to gain other properties, which could make perfect sense. In the above example you trade decentralized trustless for high efficiency but trusted (users need to trust you and some other parties involved, and the government(s), and... ).
Bitcoin itself has as primary property that it's decentralized. Uncensorable, low barrier to entry for miners and for full nodes, peer2peer and all those good things are very much related and intertwined with that primary property. 600MB per block would completely destroy all that.
That is not to say there aren't many way cooler tricks that Bitcoin has up its sleeve. SegWit is currently being rolled out and will make making blocks smaller for certain nodes and better prunable, while making the effective blocksize around 1.75MB. As well as opening up paths to many more cool efficiency improvements like making multi-sig transactions significantly smaller.
An even bigger step will be made with two-way payment channels and networks built using those. Lightning Network is most well known name in this space. The idea is to cache hundreds and thousands (or orders more) of small transactions over weeks or months without putting a single one in a block. Only at the very beginning when opening such a channel and at the end when closing the channel will a transaction actually end up in a block. Organising these channels in a peer2peer network allows anyone to send and forward money through multiple hops, thus allowing everyone to pay anyone else without having to trust a single node and even having true instant and trustless payments (no need to wait for block confirmations).
Scaling is seldom simply turning one dial merely making an existing thing larger. Clever solutions have a much bigger impact while offering better trade offs.
Excuse me for not answering your exact question of listing all impacts of switching to a large block size. They are numerous and each can lead to its own endless bike shedding and handwaving discussion. The most important is that once a block has been mined it needs to propagate ASAP around the world or there's a risk that another miner will find another block where one of those blocks will be "orphaned" (wasted). More orphaned blocks leads to more centralized mining, as bigger miners have a bigger chance to win such an orphan race. "ASAP" in the case of a 10 minute interval is therefore on the order of seconds. Now that doesn't mean that the whole 600MB would need to be transferred to all nodes around the world within a few seconds, but it's still quite a challenge.
Currently 2MB is deemed the maximum safe blocksize, which SegWit pretty much covers. After further enhancements and efficiency improvements another doubling is likely possible in one or two years.
