When secure email, is not really secure
Since raw emails are not encrypted, what you can read in an email could have (conceptually) been read by anybody. However, to read the email, the attacker would still have to connect to the HTTPS server, which leaves tracks (the IP from which the attacker connects will be known to that server — of course, that IP will probably be that of a Tor exit node). The link-in-email system prevents passive-only attacks: the attacker has to send some IP packets of his own at some point. This is not a huge increase in security…
Usually, promoters of solutions such like the one you describe do it for security, but not your security. They want to know when the email was read. This is a preventive measure against people who read embarrassing emails and then claim they never received them. It won’t be much of a proof, but it may be sufficient to counter evasive maneuvers from some uncooperative co-workers.
If you want a system which guarantees that only a specific individual will be able to read the email, then you need to define what specific individual you are thinking about. In the world of computers, everybody has a computer, and they are not immediately indistinguishable from each other. People have physical identities which are not part of the computer world, so a link must necessarily be made at some point. Standard secure email solutions like S/MIME do that through a public-key infrastructure: a recipient is defined by being “the guy who controls the private key corresponding to the public key which is in that certificate”. This moves the problem of physical identification to a single preparatory step during which the certificate is issued.
A possible model is that you met the recipient in person once, and he gave you his business card; on the card is printed the fingerprint of his OpenPGP public key — you then find the key from a public key server, and check the fingerprint. There are many variants on this concept, but a non-computer physical contact is necessarily involved.