Scalability in SMPP protocol is complicated matter. You can scale horizontally by firing multiple connections but this creates issues like Status Reports coming back on other connection than the message has been submitted, if one account is used. Vertical scaling is not only on the component (but of course badly created component can limit the throughput) but quite often is limited by the SMSC itself - it is hard to find an SMSC that would not saturate over 100-150 messages per second returning throttling error (0x00000058 - ESME has exceeded allowed message limits). Concluding - achieving high performance may require cooperation with operator. Component/library may come handy if it has e.g. throttling or submit to multiple destinations support built in.
Robustness is another rather subjective thing but in my opinion good & preemptive support are a part of it.
Fault tolerance can rather be only achieved in cooperation between component/library and the application that is using it. Library cannot do all the things like retrying submits, dealing entirely with throttling, responding to errors in submit_multi operation etc. This would call for a queuing/buffering mechanism and would certainly interfere with high throughput for basic operations. It would rather be an SMPP gateway if you would like it to deal with all errors that may appear. But with good library all this can be done easily for starters and the fine tuned with growing performance demands.
This commercial .NET library may be worth considering:
http://www.tops.com.pl/en/products/smscc/
Has quite large number of installations, quite few by large telecoms. Can be used in scalable manner both horizontal & vertical and can implement fault tolerance scenarios. In real life tests achieving over 500 messages per second on single TCP/IP link, limited by the SMSC's capabilities.
