Hehe, that's actually one of the things I find a bit confusing in the Unity-API ;-)
Notice that they say "Base class for all objects Unity can reference." (emphasis added). So it's not the "Base class for all objects" but the base class for those objects that "Unity can reference" (which, admittedly, can seem a bit mysterious - what exactly does it mean that Unity can reference those objects? ;-) ).
In my opinion, what they call "Object" should rather be called "UnityObject" because it's not really just the generic object: In .NET/Mono that generic object that everything inherits from is called System.Object, and in fact, Unity's "Object" inherits from that - and all objects in the Unity API also inherit from that, even though it's not explicitely stated. What you see as "Object" in the scripting reference in reality is actually UnityEngine.Object. That's the full name of it - but that's something you can hardly see from the API-documentation, but you may have noticed that in Unity C# scripts, you always need
using UnityEngine;
... which is what makes all the classes from that namespace available to you (and in fact, pretty much all the classes you find in the scripting reference in the section Runtime classes live in that namespace, String being one noteworthy exception - string is a .NET class that actually lives in the System-namespace, so that would be System.String when you have it fully qualified ... and in fact, it is a lot more powerful than what's documented in the scripting reference: see the real System.String ... but don't get confused ;-) ).
So, this UnityEngine.Object is a game engine specific class that has an instance ID and that can be looked up with FindObjectOfType and FindObjectsOfType. Also noteworthy is that these game engine specific "Objects" can be (and have to be) explicitely destroyed if you want to get rid of them: Object.Destroy. Usual objects automatically get cleaned up by the garbage collector when you no longer reference them from variables. And those special Unity "Objects" can (and must) be instantiated with a special method (which is usually executed by the editor): Object.Instantiate.
Usually, in object oriented programming (or at least: in C#), you instantiate objects with a language feature - not with an API feature (forget about Singletons and Factories for a moment; that's advanced stuff ... less advanced than Unity's "Objects" but more advanced than my example here ;-) ).
You can say:
Random myRandom = new Random();
In that case new is a language "feature" that instantiates a new object. Random is an object, and it obviously doesn't inherit from Unity's "Object" class. It's not even aware that this class exists and can't be aware of that because it comes from an API (.NET/Mono) that is "below" Unity (in other words: Unity is built upon it, not the other way round - that's "package dependencies" in oo-speak).
I think one more thing that's important to know about those Unity-specific objects is that they don't only exist in the .NET/Mono space but also have their "counterpart" in the native Unity game engine. In other words: Those "Objects" are much more than any usual C# object, which explains some oddities (like you get very weird behaviors when you directly instantiate those ... see the forum posting I linked below for an example). And I think this is also what they mean by "objects Unity can reference". The low-level game engine "knows" about these objects and can access them because they live in both worlds (the native C++ engine world and the scripting .NET/Mono world).
So, in the end, all classes that don't inherit from UnityEngine.Object are simply Mono-classes, and if you instantiate them (with "new" in C#, without "new" in UnityScript), you get Mono-objects (which I sometimes call "pocos" - plain old C# objects ... which I derived from "pojos" - plain old java objects, a term from the J2EE context; or simply "vanilla objects" ;-) ).
What's called "Object" in the Unity-API is not just a C#/UnityScript/.NET/Mono-object but a very special kind of object in the Unity-space, actually, I'd say it's something very magical ;-)
Finally, not all "Unity-objects" appear in the Asset-Manager - but I think you could say that everything you see in the project pane (what you refer to as "asset manager") is represented somehow as "Unity Object"; except for folders (and things that Unity can't import ... but I haven't tested that - might be things that Unity can't import end up just as instances of "Object").
Btw, when I first learned scripting with Unity, I ran into an issue that appeared extremely weird to me, which is somewhat related to this (and I was really confused back then): Huh? varName != null is false, when varName is not null?; in particular, see Keli's answer.
Also related to this is this little statement in Overview: Writing Scripts in C#: 7. Avoid using the constructor.: It's important to understand that this refers speficially to MonoBehaviours - part of it probably refers to anything derived from UnityEngine.Object. It does, however, not refer to any of those objects which are instances of classes not derived from UnityEngine.Object.