If you are reading this, that might mean that you have opened this question (or maybe previewing the question). If you have indeed opened this question, when you click on the question title it links you back here...
Why do sites like facebook, google and even stackexchange do this? What kind of impact does it have to the user experience?
Typical users aren't going to expect a headline title to link anywhere, so there's potential for confusion there, but for power users this link gives additional functionality. On balance I'd say this isn't an anti-pattern as such because of the additional functionality it provides.
EDIT:
I've found a similar question from webmaster.stackexchange, which has some interesting rationales, including links back to the original from mirrored articles, and the ability to perform "safe refreshes", which don't resubmit POST data.
For contrast, Wikipedia has some guidelines on self links (interestingly, this formatting only applies to the articles themselves and the "Read" link is a self link). They seem to believe that self links are likely to cause confusion - and in the context of Wikipedia's linking pattern, where they're liable to turn up half-way through the article, this makes sense.
I don't know why these links exist on Stack Exchange. But we see them on many sites … maybe just a bad UI tradition.
There is one use case: People may have been found to this page per newsletter. The URL will then look like:
http://ux.stackexchange.com/questions/21729/why-is-there-a-link-to-the-current-page?newsletter=1&nlcode=51162%7c8257
That's not the URL you want to see in your bookmarks. To get the clean URL you have to remove the parameters manually – or take the link from the head line. The headline is also easier to drag with a mouse than the URL.
Besides that I consider redundant links a rather poor UX: Selecting the title may lead to an unintentional click, and a keyboard user gets an extra, useless step on her way through the site.
I have written a small WordPress plugin to remove redundant links some time ago (doesn't work very good) because in WP, like in many other CMS, these links exist just because the underlying code is rather inflexible or nobody has asked your question.
I can only talk for myself, as I am a great fan of that: Links to the pages themselve enable you to easily post them on Social Networks, Instant Messengers and E-Mails. URL often contain unnecessary parameters, or worse: sometimes even parameters that reveal personal information about you. That can pretty much suck when you post stuff in public Chats/Forums/Blogs.
Another thing is HTTP Post: especially when you are on such user-content-driven sites like Stackexchange, you often do POST-operations. Pressing F5 after a POST operation gives you this ugly and annoying browser window: "Do you really want to reload and post..?" If you accidentally click "OK", you posted your stuff twice with even more annoying consequences.
Fortunately a lot of Websites employ the POST-Redirect-GET-Scheme (or completely javascriptized posting) so on good pages like Stackexchange you don't have that problem.
Anyways, it makes navigation and sharing of User driven Web content much more predictable for the user. Meaning less stress and more fun.
(Sometimes I wished Google would provide links to their searches. Particularly after they introduced that instant search, rendering the browser URLs more or less useless. Pretty cumbersome when you are a fan of sharing hyperlinks.)
EDIT: last but not least: sometimes the URLs on top of the browser are not valid for an infinite amount of time. (cf. "Permalinks") And in the age of Web apps it becomes preferrable to not see your Address bar so often. On small screen devices the user may not want to see that extra waste of space as less often as possible.
I think this feature supports three desirable aspects of the site:
Linkability: An article should provide a link where it can be found. This can have additional benefits such as being a permalink or a link without any navigational parameters, as pointed out in other answers. Ultimately, though, it is a way for the reader to determine the URL of a page (for finding the up-to-date version again, for passing on the link to others, ...) as opposed to the current URL of the file they might be reading.
If the article is read in its original location, the browser's address bar may serve as an alternative way of retrieving that URL. However, relying on the address bar is a design mistake IMHO - for all we know, the page might be displayed in a frame/iframe of sorts, or the browser might be running in some kind of weird kiosk mode that does not allow the user to access the address bar. Moreover, all the other URLs to in-article resources (e.g. on Stack Exchange, links to single answers or comments) can be obtained by finding the appropriate links on the page, so getting the article's own URL via a link, too, seems fitting.
Testability (of links): My main point above has been retrieval of the URL. Now, there would be several ways to do that - the URL might also be written verbatim or in a text box, ready for copy-and-pasting. However, by providing an actually clickable link, the URL that users might copy via the context menu is testable right away. It only takes a single click to verify the link really does point to the desired resource, before copying that URL to some other destination.
Consistency: If the title of an article is a link to the article on some pages of a website, it surely should be a link to that article on all pages of that website. Anything else would be inconsistent and thus confusing.
You can often reach a page via a link to a topic within the page (with an address with the '#' character in it e.g. http://www.site.com/pagelink#topiclink).
In some sites the address bar does not change when you visit internal pages.
In both of the above cases, if you want to send a link to the top of a specific page or bookmark it, then you need a link to the top of that page (in the first case you can edit the url yourself if you want).
From examining this website, I can see why the title link here does it. Looking aat the page source code I see the link is in the (class="question-hyperlink"). That is here at the top for the article, but it is the same link and class when the article excerpt is displayed in the question page. Each Question has its own div with the link, excerpt and other special items.
Doing it this way for this site and one like it reduces the amount of rework and site code. Another good reason would be if someone decides to copy an article they will get the link as well, so if they post it to another board or in a newsletter etc. someone can follow the link to the original article.
That's fine for articles, but in the case of nav menus, I prefer a standard whereby buttons are disabled for the current page and either hidden or ghosted. It is more work to do so, and many people working in the industry are lazy and probably should be doing something else for a living, so you should be prepared to see almost anything.
