Hmm, it seems funny seeing one of your answers quoted!
In order to support high availability in Sharepoint you definitely have to cluster the SQL servers. There is no other realistic choice. In regard to the web servers, Microsoft's NLB only supports hardware high availability, if the web application fails, it will still send page requests to a partially running or corrupt web application. Indexing (crawling) can only run on one server in the farm. However, if that server dies, it simply means new content isn't being added to the content database, search will still work if the query services on running on other servers. Luckily you can get indexing up and running on another server quickly. If hardware isn't an issue your safest strategy is use lots of servers on the farm and make sure everything is redundant.
In regard to my experience and knowledge of Sharepoint read this case study:
http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?casestudyid=4000004267 That is my team's work.
Based on my discussions with MS Sharepoint Rangers and support, replication is not viable and not safe. I'm involved in a heated discussion with the Sharepoint product group regarding the core configuration design and am winning. Here is the problem, the database and servers are tightly coupled. Unless the database snapshots are all matched to almost the exact same date and time then Microsoft has told me the servers will be in an 'unsupported' state. The problem is how do you backup a running farm (even with shipping logs) to be 100% sure they are all in sync? Even the Microsoft engineers can't answer that. Worse yet, the replication can replicate the problems if you keep the delta between replication events too short.
So rather than having hardware sitting in hot standby mode that isn't servicing customers why not have the running farm fully redundant to suit both high availability and provide great performance? If you are really worried invest in a MOM server or similiar to monitor the running farm for problems. We still do nearby backups of our content and config databases (we don't backup the index because it' has to be rebuilt if there are big problems) but our reliability is lot's of duplicate hardware participating in the primary farm.
