Yeah, it sounds great in theory, but what makes you think it can be done without a fork?
To the extent that sidechains need a fork for efficiency, I'd support it fully. Meaning that I'd accept it, and it's very possible that I'd start running a full node again (and maybe at home behind my satellite connection if certain other 'good ideas' don't make it into the codebase.)
Currently, bitcoins exist on the blockchain and they are controlled by the private key. They can't magically disappear from the blockchain and come back later as it currently stands. Even when they are sent to addresses that aren't revealed yet, the owner of the relevant private key still controls them and the blockchain is still tracking them. That having been said, my understanding of what you are describing is that either you still have the bitcoins and still control the private key, in which case they aren't moving on a sidechain and you are issuing IOUs on the sidechain, or you've given the bitcoins away, trading them for IOUs in the sidechain while trusting someone to reimburse you in the future for the ones you didn't spend. Clearly one of us is understanding something wrong.
That having been said, even if a decentralized system that we could trust to manage our private keys existed so that we could send bitcoins to the "sidechain" (by giving up a private key or sending to an address assigned to us but controlled by the "sidechain" [this example wouldn't actually be a chain, it would be off-chain, which is already possible if you don't mind IOUs from a centralized party]), you'd still have to trust that "sidechain" to properly allocate the bitcoins in the blockchain at some point, and for it to be any more efficient when someone "repatriated" (really "withdrew" their microtips (from your example), it would have to behave as a mixer of sorts, maybe taking the sum of the microtips from the private key you "deposited" to and repatriating your leftover bitcoins to an address you control from someone else's "deposit". This is in no way simpler than the proposed fork, and it doesn't necessarily resolve the underlying problem.
I've always visualized sidechains (before they were named) as efforts which are not free of work. People involved in a sidechain effort would have basically the same set of responsibilities that the people involved with Bitcoin have in order to make me wish to use (or participate in) the effort.
The SC whitepaper anticipates some not insignificant latency involved in securely moving between the bitcoin blockchain and the sidechain. I've always imagined such transfers as being aggregated operations which would add somewhat to the latency. Say, for instance, once an hour adjustments to the backing store were performed. I'm fine with that as long as I can have confidence that my value on the sidechain is protected in a reasonably sound and unexploitable manner, and this seems technically quite doable to me (though hardly trivial!)
In practice I would probably almost never do an actual proper Bitcoin transaction. It would be an event like going to my safe deposit box which I maybe do once per year. I would, however, likely be transferring from one sidechain to another sidechain on a very regular basis, and behind the scenes a variety of aggregated operations would be doing the heavy lifting. Many of them probably need not even result in one actual Bitcoin transaction. Obviously I would only be using sidechains which are operated in a manner which is on par with Bitcoin in terms of the confidence I have against exploit.
In the manner so described I would in fact be using Bitcoin fully insofar as I acquired some fraction of the Bicoin currency base and maintain unique control over that fraction, but I would be doing so with minimal burden on the actual blockchain.