Some of the reasons those coins didn't succeed:
1. Some pre-mine or "test" mining.
2. Some difficulty 0 and had a lot of hardware ready with their insiders
3. Some difficulty 0 and get over-mined since the very beginning before nodes are well distributed
4. Some only got mined at the beginning when it was easy and then they stopped
Why is digitalcoin different?
1. No pre-mine or any semblance of it.
2. Number 1 again.
3. digitalcoin had very low rewards at the beginning so coins didn't begin to be distributed in quantity until many people could participate
4. It is more profitable to stay with digitalcoin due to the nature of the reward system
1. Some pre-mine or "test" mining.
2. Some difficulty 0 and had a lot of hardware ready with their insiders
3. Some difficulty 0 and get over-mined since the very beginning before nodes are well distributed
4. Some only got mined at the beginning when it was easy and then they stopped
Why is digitalcoin different?
1. No pre-mine or any semblance of it.
2. Number 1 again.
3. digitalcoin had very low rewards at the beginning so coins didn't begin to be distributed in quantity until many people could participate
4. It is more profitable to stay with digitalcoin due to the nature of the reward system
DigitalCoin won't succeed for a different reason. The chosen block time is actually too short. I write about why that's a bad thing here: https://bitcointalksearch.org/topic/coins-with-very-short-block-times-demonstrate-incompetence-211535
I read that. Good thoughts. One of the developers who took part in this project did take care of that for us. Check the pool rates for the orphan rates and efficiency.
What exactly did the developer do to prevent these issues? Note that the issues I present only become apparent once the distributed network becomes large enough. Low orphan rates now doesn't necessarily prove anything, it likely just means that the network hasn't grown large enough for these problems to become apparent yet.
We are still in beta and working on documentation. You can check the source and see the changes yourself.
The only relevant thing that I see in the source diffs is that MAX_OUTBOUND_CONNECTIONS was increased from 8 to 16. Is that the change made to avoid these issues? If so, can you articulate why you believe that is sufficient?
That is one change I am aware of.
With fast blocks, one of the main issues is latency and propagation of the transactions through the network. More connected nodes means more ways for the transactions to be routed in case of a dead or unresponsive node in the network. It also means clients are able to connect to more nodes and lower the probability of a latency and therefore a fork in the network. It is under the basic principal that a faster network functions more optimally without bottlenecks. The faster a consensus can be reached and transmitted, the better.
Everything is going according to plan up to this point.
But on another note, I wouldn't worry too much about the displayed hash rate at a pool. Its only an estimate in the best of cases, and with new/quick coins sometimes the operators need to tweak some of the calc's to get it right (I am still doing that on mine as well), but either way it does *not* generally affect your payout rate (or shouldn't anyways) 
