We use number 1.  I think you are probably asking this more because of traditional test plans have a lot of what I would call "boilerplate stuff" in them.  That makes reviewing them harder as you describe.  Test plans are really containers of test cases and execution plans with objectives.  We consider the "meat" of the plan to be the test cases and they go through a separate review/approval process with development and other interested parties.  Once they are approved they are considered as "fixed objects" until someone opens a workitem or task asking for the test case to be enhanced or modified - then it goes through another review/approval process.  The test plan review becomes simpler to review because you can look at the requirements the test plan claims to validate, are the appropriate test cases associated with the test plan to validate those requirements and do you have the right mixture or coverage of test environments. 

The review allows for comments and responses to the the comment much like what is done in work items.  I am an approver of test plans and I will not approve a test plan until test plan owner has addressed all comments by responding to each comment in the review section and the reviewer has agreed by approving his/her review.

By exporting the test plan which 2 and 3 do - you lose this type of dialog or you have to manually have to re-enter it.  It takes time for some people to get used to this methodology but they adapt - we have been doing it this way for over 5 years now and it is generally accepted by our users.

Dave