Sajid,
1) What Greg was trying to explain was that the File and FTP adapters don't really "load balance" in that sense. If you put two bts servers to monitor the same remote folder on a server using the FILE adapter, for example, you're very likely end up pulling messages twice. Certainly not what you intended. What's recommended in such an scenario is to cluster the BizTalk servers so that only one is active at a time (hence only one is actively polling the remote folder); if that server fails, clustering ensures the other server picks up, thus achieving high availability.
Regarding MSMQ, the basic problem is similar if you're using non-transactional queues. However, this is rarely the case in many scenarios. if you're using transactional queues, then the core limitation here is that MSMQ doesn't support remote transactional reads. That means that the queue itself needs to be located in the actual biztalk server for it to be able to read messages transactionally, and thus no way to load balance anything there. Again, you can cluster both MSMQ and the biztalk host associated with the MSMQ receive adapter to achieve HA.
2) MSMQ really, really doesn't lend itself towards load balancing. There are a few articles around about working around using intermediary servers that distribute load, but that's not really very useful with BizTalk since it already can do that internally. As for Websphere MQ, I don't know much about it so I can't answer that part.
3) The trick here is to remember that BizTalk does a lot more than just receive messages. It also processes them (orchestrations) and sends them. Receive, Send and Orchestration processes in biztalk are completely independent. For orchestrations and sending, biztalk automatically load balances the operations if the associated handler (host) has host instances on multiple servers. So, for example, if you have a Host A with instances in servers S1 and S2, and that host has an orchestration configured to run on it, biztalk will automatically execute some orchestration instances in S1 and some in S2.
In other words, the larger problem with HA and scalability in biztalk (from an architecture perspective) is usually with receive-side adapters; send side adapters and orchestrations are much easier to handle.