When it comes to graphics, the term "culling" by itself doesn't really have a single definition or location within the pipeline. The term is sometimes applied to primitives and it is sometimes applied to fragments. It is sometimes applied to faces based on orientation relative to the camera, and it is sometimes applied to primitives based on various parameters. So it's not useful to talk about "culling" as though it is a single thing; there are a lot of things called "culling".
By contrast, "clipping" with regard to the graphics pipeline is almost always used to refer to what happens to the vertices of primitives after any programmable shading, but before rasterization. Clipping happens differently for different kinds of primitives, but the basic idea is to take a primitive and split it into one or more primitives, such that all of the new primitives are entirely within the clip-space volume.
If a primitive is partially outside of the clip-space boundary, the process of clipping creates one or more new triangles that are entirely within that boundary. The clip-space boundary, through the viewport transform, defines everything which is visible with the current rendering state, so if something is outside of the clip-space boundary, it is not visible. Well, in theory; in practice, there are ways to draw stuff outside of the viewport (point size, line width, multisampling, etc), but nevermind those now.
Now this describes the abstract model of how OpenGL and similar specifications talk about rendering. What actually happens in the hardware is often a different matter. Because clipping has the potential to generate many primitives from one (and thus make the pipeline choke a bit, since it has to run more rasterization cycles), hardware tends to avoid performing actual clipping unless absolutely necessary. So the notion that it is a performance optimization is not really true.
Note that a primitive which is entirely outside of the clip-space boundary gets clipped into nothingness. This particular case is often called "culling" the primitive, which is why the terms sometimes get used in similar places. Point primitives are either rasterized or culled; they don't ever undergo real clipping (since there is only one vertex). But overall, this process of reducing primitives to those within the clip-space boundary is referred to as "clipping", not "culling".
Clipping also allows users to define some user-defined clipping parameters, which clip primitives based on values provided by the previous vertex processing stages. You can use these to implement clipping planes, such that primitives are clipped at the intersection of an invisible plane. All parts of a primitive on one side of the plane are visible, but not on the other side.
Things which are referred to as "culling" formally within rendering APIs:
- Face culling. Discarding triangle primitives based on their winding order relative to the viewport.
- Vertex-based culling (a relatively new feature), whereby entire primitives can be culled based on vertex processing parameters.
The article you're talking about seems to mostly equate "culling" with visibility culling techniques. These are computations implemented by user code which chooses to render or not render an object based on whether it is visible. These can range from the very simple frustum culling test (ie: asking if the object is even close to the visible region) to complex BSP systems or portal visibility culling (which attempt to detect if objects are entirely behind static geometry). But these are not part of the GPU's rendering pipeline, even if GPU processes are sometimes used to do such testing.
Overall, that article gets more wrong than it does right, so it's best to just pretend you never read it.