The procedure you describe seems to be the conflation of two distinct procedures which apply to distinct contexts.
1. Registration for a targeted individual
There are some contexts in which the registration is for a specific individual, with a defined physical identity, and occurs in a process which does not allow the setting of a user-chosen password. An example is when you "register" someone who you met at some trade show, and who gave you his business card. You know his email address, but when registration takes place, the user is not there. In such a situation, you have to send him a way to initially log in to your system (with at least some level of authentication -- you do not want to create an account for everybody, just for that guy) so that he could complete the procedure by choosing his own password.
An initial password, sent by email, and which must be changed upon first usage (enforced by the application), is one way to cope with that context. Sending him a "unique registration link" which brings him to a page where he can choose his password is, from a security point of view, exactly the same thing.
This is a non-ideal situation, in that the initial credentials must travel unprotected. Forcing password change upon first usage is a mitigation measure: yes, an attacker could intercept the initial password / validation link, but then he would have to choose a password himself, and at least the intended user will notice the problem (by not receiving the email or not being able to log in).
2. Registration for "anybody"
Most deployed Web apps which use registration work in a different context. Consider a Web-based vendor of some goods (think Amazon). Here, you accept anybody as new user. You need to "register" users because you want users to be able to keep track of their commands, and they should not be able to see the commands of other people.
In such a context, the user is available during the initial registration: he initiated it, he is right behind his keyboard at that time, and he can type in his chosen password under the cover of HTTPS. The Web app can accept this kind of registration because it is not picky: by design, anybody is entitled to register.
You still need a "validation link" sent by email, but for a very distinct purpose: the validation link is used to make sure that the email address is genuine. An attacker intercepting that communication could fool you (i.e. register under an email address which he does not "own" -- although he can intercept emails sent to that address, so he really owns it, to some extent), but such an attacker would not attack the same thing than in the first context. In the first context, the attacker impersonates the user who is entitled to log in; in the second context, the attacker is entitled to log in anyway, but he succeeds in doing so while providing the email address of someone else.
Summary
Sending a one-time initial password through email is a good or bad thing, depending on what kind of registration you are running. For a classical Web-based account creation that anybody can do, this is bad. For registration of a specific individual, the enforcement of a password change from the initial password is good, because in that case you already had to sent it by email, which is a security hazard (you just had no choice, and you must mitigate risks).
