There are choices for a reason: each has advantages and disadvantages.
There are basically three you should think about. (Anything else is either irrelevant [very old] or not well supported.)
1. HTML 4 Loose
This is for lazy coding if you don't want to deal with the validator giving you errors about things that work but are technically "wrong" or "don't exist". This is the default for many WYSIWYG editors (like dreamweaver), but it's not really a good idea to use it. It's like using a half doctype (loose), so why bother at all?
On the other hand, one advantage of this is that you can use certain things that may be specific to a single browser (like internet explorer) so that you can compensate for a browser not following the standards. And you can do things like build your own tags that are ignored by the browser but perhaps relevant in Javascript-- but generally these reasons don't outweigh the laziness of using a "Loose" doctype.
It's also known as transitional, for those switching sites slowly to HTML 4 standards.
2. HTML 4 Strict
This is probably the 'best' based on the current state of the web. It's the full and strict version of HTML4 and will require attentive coding and checking with the validator to get it to validate and work across browsers.
There's nothing special about this, but it's stable and well supported. One major problem is that while this IS the standard, some browsers (again, consider internet explorer) ignore it and you will need to choose (in some rare cases, but not so rare actually) between a page that works in all browsers and a page that validates.
This the proper target, but may make extra work for you once a page is already working across browsers. The best coders probably use this.
3. XHTML [strict? transitional?...]
XHTML is the big new thing to hit the web. The differences seem minor, but for coding can make a big difference. The most notable is that tags MUST be closed, so either <a></a> or <br />. In html you can just use <br>. In XHTML tags are also case-sensitive, so watch out when converting pages. Personally I think XHTML is kinda silly.
But it's the new big thing as I said and it's very popular. You'll find that a lot of things such as forum packages tend to now be in XHTML rather than HTML.
I'm not even sure what's so great about XHTML, but people seem to like it. For one thing, it moves on from HTML to XML which is a multi-purpose code setup that allows for things like data storage, webpages, program instructions, archiving, etc., all within the single framework. Moving HTML into XHTML means using a wider standard. I suppose that's important.
So XHTML has a lot of support. What's wrong with it?
1) It is NOT well supported. I'm not sure what version of IE finally supports or will support XHTML, but certainly not many users. IE will just ignore the doctype and guess about what to do with the code. You may as well not use a doctype in those versions of IE. And some other browsers don't support it well either, but most of the major ones do now.
2) It is rigidly different from other HTML, so why bother learning something you don't really need when HTML is the primary standard?
3) For a while it was the new big thing and going to be the future of the web, but now it sounds like HTML5 is back on track for taking over some time soon, so XHTML is just a random stop along the way and without even ever being fully supported will soon be passed for HTML5.
Note that HTML moved to XHTML will not function well. Also note that XHTML moved to HTML is generally backwards compatible, such as how it's always parsed by IE-- as messed up HTML, not XHTML. BUT even though XHTML will function as HTML, it probably won't validate.
The other options you have are:
1. No doctype. This may be said to be a horrible idea, and it probably is, but without a doctype the browsers will guess and figure out what to do. But some features may not be enabled then. Only for lazy coding or for REALLY unusual requirements would this make any sense. Generally it's a bad plan.
2. Prepare for HTML5. It's coming. Not sure when, but it's coming... It certainly isn't time yet, but it may standardize things significantly so that may be the real "answer" to your question and for now just use whatever you pick.
Finally, remember the most important part of all this is that standards HELP make the web work, but aren't required for any individual page to work.
What this means for you is that you should make every effort you can (within reason) to create a standards-based page. But if one or two things on the page aren't within the standard and won't validate but work across browsers as far as you can tell, there's really nothing wrong with that.
The two reasons that you should always try to follow standards are:
1) They make it much more likely that all browsers will parse the same way. If you're not following standards it's just as likely that they'll be parsed differently as being parsed the same. But sometimes this isn't a problem. One example is adding an extra tag that only works in one browser: it'll be ignored in the others and may not validate-- but it won't hurt anything.
2) If you ever want help (such as on this website) using standards is the best way. If your code is too different from what others are used to, they may just not know how or not want to spend the time trying to help. But if you've got a couple places where the code deviates that won't be a problem.
The bottom line is that you should pick a standard and 98% of the time stick to it. Pick a goal and if you do deviate, have a good reason why.
Basically, I'd recommend HTML4 Strict at this point. But others may disagree.
Note that any doctype (even transitional/loose) will greatly improve the overall consistency of using the page across multiple browsers.
I hope this works as an overview. It's not a simple question, even though it may seem so on the surface.
It's similar to wanting to learn English and asking what variety you should learn-- American, British, Australian, Indian, or some dialect therein.