The reason to use the content pipeline can be found in the Microsoft XNA documentation.
The chief reason XNA Game Studio uses a Content Pipeline is to help your game run fast. Without the content pipeline, your game would have to be built with its art assets in their original file format. When the game needs to load its art to draw it on the screen, it would have to determine its format and convert the data into a form it can use more directly. This would have to be performed at run time, for each asset, making the player wait to have fun.
The downside is the extra effort required to setup a content project and manage the process of building your optimized XNB files. Here's a quote taken from the link in your question for clarity.
The trouble using XNA content builder outputs on other platforms is that the XNB files it outputs are platform specific, MonoGame has gotten around this with its own multi-platform builder project allowing the creation of compiled assets for all its target platforms. It’s one deficiency is that it depends on the original XNA content project template which is still only available in VS2010 (express will do). Fear not however there are plans for a more open source version.
As you have already discovered, with MonoGame it's not necessary to use XNB files because you can add the raw content directly to the project. For a smallish project I think that's fine. It's what I've been doing with all of my projects thus far and I haven't had any issues (yet).
A word of caution though, things may change a little once the MonoGame team have finished implementing their own content pipeline. Here's a quote from a forum post I posted a while back.
It's not necessary to use XNB files. They are simply the format that the ContentManager reads (MonoGame's ContentManager currently reads other formats such as JPG, PNG, etc, but that will be removed when we get a Content Build Pipeline going).
The benefit to using XNB is that it is pre-processed into a format that is ready to be used directly by the GPU (in the case of GPU assets). Loading a PNG requires decompression of the PNG, perhaps some channel swapping (red and blue particularly) and then copy that uncompressed data into a Texture2D. If the texture has alpha, you would most likely need to pre-multiply the alpha for every pixel yourself. This is all done at load time. For XNB, the decompression, channel swapping and most importantly, pre-multiplication of alpha is done at build time. You can also optimize further as I have done in some of my games in that I output a dithered 16-bit texture to the XNB to save on memory use and bandwidth rather than the 32-bit default format.
Loading from PNG is fine if it works for you. There are some trade-offs for the convenience, but they won't matter to most developers.
Lastly, if you do decide to go down the Content Pipeline path, this documentation might be helpful.