I find it interesting that this library requires the creation of a "printer" object instead of the (IMO more standard) definition of operator<<. Is there any specific reason why the author chose to go this way?
So making an object for printing probably helps with scope issues like that.
I was sad that they were spending a bunch of resources on that relatively useless stuff, rather than a sorely needed set of standard collection classes, not to mention a string class. And by "standard" I don't mean actual standards -- it was far too early in the game for that -- but even just enough to get by.
If you squint enough, it looks like a fluent interface, just fluent interfaces wouldn't become mainstream until later. That is, "cout << a << b << c;" is pretty close to "cout.print(a).print(b).print(c);"
Another reason to use an operator is that if you use free functions (without variadic parameters) then your parens and nesting stacks up: "print(print(print(cout, a), b), c);"
An infix operator doesn't have that problem.
In modern C++, there is at least the possibility to replace "<<" with something better for printing.
My guess: because it has very low precedence, allowing stuff like:
> cout << a + b * c << " is the result\n";
Instead of:
> cout << (a + b * c) << " is the result\n";
edit: the similarities are pretty obvious, but for those too lazy to Google, see https://docs.python.org/3/library/pprint.html
Edit: this also lets them assert on argument types.