The record type selection page is only displayed when needed (meaning whenever the record type cannot be pre-determined). The page is skipped when either 1) the user's profile only has access to one record type for the object or 2) they've set a default record type in their personal settings (setup->my personal information->record type selection).
The output of {!URLFOR($Action.Task.NewTask)} takes this into account and will direct a user to either the record type selection page or the new task page depending on whether any of the conditions above are listed.
You can use a technique referred to as "URL Hacking" to accomplish this.
The idea behind URL hacking is that when you're writing a button, or a link -- anything with a URL, you can pre-populate certain fields with data from the URL itself.
First, a little background. Forms -- those bits of a web page that accept information from a user have two general ways of transmitting that data back to the server. 1: POST DATA, this is the more advanced but more common data transmission method as it allows for things like file uploads, and much larger forms. 2: URL Parameters, This is where each form variable is HTML Encoded and appended in a key=value format to the URL. You've no doubt seen this where the URL's look like: www.example.com/awesomePage?id=123&variable1=hello&varaible2=world
In general, while not officially supported, most salesforce pages will accept inputs through URL parameters OR POST Data. Thus, if you know the key of the data you want to set, you can set that data via a custom button by appending that key=data bit to the url. There are a couple of considerations to keep in mind, however. 1: The first key,value pair is demarcated from the page url with a '?'. After the first key,value pair, all others are separated by '&' signs. Remember that url example from above? note that the id=123 has a ? before it, but variable1 and variable2 both have &'s in front.
Now the hardest part of this is often discovering what the name of the KEY is. Truth is, you can always find it from reading the source, but that is often an exercise in mind numbing frustration. HTML is too <<< >>> pointy.
https://www.squarefree.com/bookmarklets/forms.html has a list of form related javascript bookmarklets - One of which is called FrmGet. FrmGet will translate POST Data forms to Url Parameter forms which can make it easier to find the key your looking for.
So if you've read this far -- Congratulations, you know the theory behind what you want to do. Bored yet? In the end what you want to is create a button that has a url something like instance.salesforce.com/path/page?recordTypeId=<<<RECORDTYPEID>>>
Best Answer
The reason the two different actions exist is because there are different record types that may exist which are appropriate for the Task. In some orgs, they consider all Tasks to be related to a specific record type (often related to the WhoId which points to the account) which they default it to. When that's the case, it bypasses the dialogue where they assign a Record Type.
In other orgs, it appears that's not the case and there may be more than one appropriate Record Type for a Task. When that's the situation, the user is expected to choose the correct Record Type to assign to the new Task.
For more on this, you might also want to look at this discussion.
EDIT
Here's some more from page 123 of the Visual Force Developer's Guide:
From the above, I'd conclude that its possible the org (or user) may have overridden the default properties for either the buttons or pages they're using to create tasks and/or events.
Note: There are separate buttons for Tasks and Events. Ditto for Activities. Any of the three could have custom page layouts. Events and Activities share the same "out of the box" standard page layout, which doesn't preclude an architect from creating a separate one for each of them which I've regularly seen in the orgs I've worked in.