Yes, correct. You could also use $_REQUEST but I don't recommend the usage since it contains all the data of $_GET, $_POST and $_COOKIE. In my opinion $_REQUEST is useless and it should be removed in PHP 5.3/PHP6.
They are called superglobals because they are accessible everywhere in your code even though they are just 'ordinary' variables which are normally only accessible within one level (Okay, you could use the "global" and the "static" keywords but that conveys to bad code and just makes it more difficult to understand). All superglobals are arrays. Therefore I'd check before accessing them with isset() if the key does really exist even if it might occur absurd. But imagine somebody wants to find out the local filename of your script so they simulate a POST request and leave out some fields. PHP will throw a warning which contains information like the filename where the error occured and the error type.
I'd recommend to use an own error handler in production systems anyway but it's often forgotten.

You're right. I only use GET parameters when I want to use them in links (e.g. page navigation). It wouldn't make sense to use an article ID in a POST parameter for displaying it. Otherwise this article won't be listed in most of the cases in search engines because they are not 'accessible' for them (In fact they are but they don't send any POST requests, they only follow GET links on websites as far I know). The next disadvantage is that users might want to share this article with others and aren't able to do that because you don't have a handy address which just needs to be copied and pasted into the browser in order to get the article displayed. Of course you could share the POST parameters (in this case the ID) and the full URL to the script. But it's too much work for the user to send a POST request to the server manually. For those reasons I'm only using POST parameters for user input.