It certainly didn't handle problems well back in SQL2000. It was fairly easy though to detect some of its failures to handle problems and hadle them for it, without any human intervention (that's why I say "fragile" rather than "brittle"), and in my opinion that is already enough to make it clear that the monitoring and the error management were of a standard far less than acceptable.

Far more important were the explicable errors: inserting row with already existing primary key, updating row with primary key that didn't exist, deleting nrow that didn't exist - the only thing updating the database at the subscriber was replication, there was no software that wrote to it, no-one was updating it, but these things happened. They were a big problem, because we were using replication to create a (cold) standby copies of critical databases on customer sites, and we aimed to restore service very rapidly (minutes, not hours) if a server went kaput, and servers did go kaput, now and again. If a main server had gone phut while a subscription was being reinitialised and we were left with recovery from backups we wouldn't have met that target, which would have damaged our reputation even though our contracts allowed a much longer time to recover. Servers broke simply because hardware breaks sometimes, especially if it's in a country where mains electricity voltage sometimes fluctuates wildly enough to cause damage even to kit which is certified for use in that country, or climate and computer room air conditioning is such that the equipment is being run at something quite a bit higher than its proper operating temperature, and most of our customers were in such countries and ran such computer room cooling.