It's a little hard to make sense of that page. Perhaps it was written by children or by someone selling a useless product. So let's start fresh.
Let's just discuss TCP for now.
When someone attempts to connect to a TCP port (sends a SYN packet) that you do not wish to allow a connection to, you have a few choices for your response:
1) Respond with a RST packet, if you're not listening on this port that's per the TCP protocol. Normally you'd call this a "closed" port. It would make sense to call this a "stealthed" port if you are running some service on it that allows connections from other sources.
2) Accept the connection and disconnect (RST or FIN) them immediately. TCP wrappers historically had this behavior for blocked connections.
3) Ignore the packet. This is pretty common. It would make sense to call this a "stealthed" port if you're running some service on it that allows connections from other sources.
4) Accept the connection and ignore further packets for that connection. This can annoy an attacker although probably doesn't add any real security.
5) Respond with a reasonable ICMP error. Usually done by routers (including firewalls), but not as commonly done by host-based "firewalls".
6) Respond with an unreasonable ICMP error. Just to annoy/confuse an attacker
7) Respond inconsistently and randomly. This can annoy an attacker but probably doesn't add any real security.
How you respond depends on what your goals are. If you want the machine to appear not to be a valid node, you should ignore the packet regardless of whether you have a service running (that allows connections from other sources) or not. But if you are going to respond to any traffic at all, this doesn't help hide your existence.
If you want to just disallow the connection, and aren't trying to hide that your IP address is an active one, your best bet may be to respond with an RST packet, whether you are listening on that port or not. This hides whether you have a service on that port that allows connections from some addresses, or whether no service is running on that port.
Choice #4 or #7 can frustrate someone running a port scanner, but can cause you occasional operational annoyances. It's not really all that useful for an address you're actually using, but can be entertaining for a honeypot.
Choice #2 is common because some popular filtering software (e.g. TCP Wrappers) requires the connection to be accepted to get the source address, in order to determine whether it should be allowed. This is based on historical OS limitations that might not be relevant in a new installation with modern operating systems.
Your choice will depend on your requirements. This includes whether you have any ports that you allow a connection to from every address, and whether you have any ports that you allow a connection to from some addresses.
If you are not allowing incoming connections from any source, you'd might as well drop any disallowed packets. This hides the existence of your machine, making random attackers less likely to believe that it is a valid address.
If you're allowing incoming connections from any source on some ports and from certain sources on other ports - a very common configuration - you have a few reasonable choices to pick between. If you send back a RST for ports you are not listening on at all, but behave differently for ports you are deliberately disallowing, you reveal what ports you are allowing connections to from select sources. I believe the better choice is to send back an RST regardless of whether you are not listening on that port at all or you are disallowing connections from the source.
This is exactly the kind of security question that should include a threat model, an explanation of what services you are providing to everyone vs select sources, and either a security policy or clarification that you want assistance in defining a security policy. Additional confusion is caused by the introduction of new terminology without a clear definition.