In your opinion, the oscillations are due to a too small hashing network (thus varying a lot when people join or quit it), or are inherent to such a very short block confirmation target, or something else?
I think its the first possible cause you suspected: imo, the oscillation mainly occurred because of the small user base where especially users with relatively high hashing power only contributed when difficulty was low.
Further, I think that problem can be mitigated technically by a more advanced diff/block reward adjustment (or a higher (competing) user base).
Don't forget that high blocksize provides an additional latency. If you are maintaining a fast blockchain (like SMC), you should minimize blockchain syncronization latency. Latency could cause chain forks, which will neutralize all benefits of fast chain, because REORGANIZE will be called too frequently. That's why blocksize limit should be adjusted.
True, but it might be better to further increase the max block size and also increase the target rate a bit if latencies become a problem.. but that's probably better evaluated in a faithful model of smallchange (e.g., Matlab).
Smallchange's main goal is to provide a high transaction per second (tps) rate to be feasible for micro transactions.