In fact, the << and >> operators are bit shift operators; using them for I / O, strictly speaking, is already a misnomer. However, this misuse is about as old as the operator overload itself, and I / O is the most common one today, which is why they are widely regarded as I / O operators. I am sure that if there were no precedent for iostreams, no one would use these operators for input / output (especially with C ++ 11, which has variable templates, solving the main problem that uses these operators allowed for iostreams in much more clean way). On the other hand, from a language point of view, overloaded operator<< and operator>> may mean that you want them to mean.
So the question boils down to what would be an acceptable use of these operators. For this, I believe that two cases need to be distinguished: firstly, new overloads working on iostream classes, and secondly, new overloads working on other classes, possibly designed to work as iostreams.
Consider the first new operators on the iostream classes. Let me start by observing that the iostream classes are concerned with formatting (and the reverse process, which could be called "warping", "lexing" IMHO would not be quite right here because the extractors did not determine the type, but just try to interpret the data according to with the specified type). The classes responsible for the actual I / O of the raw data are streambufs. However, note that the correct binary is not a file in which you simply delete internal raw data. Just like a text file (in fact, all the more so), a binary file must have a clearly defined encoding of the data contained in it. Especially if the files are expected to be read on different systems. Therefore, the concept of formatted output also makes sense for binary files; just formatting is different (for example, writing a predetermined number of bytes with the most significant first for an integer value).
iostreams themselves are classes that are designed to work with text files, that is, in files whose content is interpreted as a textual representation of the data. To do this, a lot of built-in behavior is optimized and can cause problems when used in binary files. An obvious example is that by default, spaces are skipped before input attempts are made. For a binary, this would be clearly wrong behavior. In addition, using locales does not make sense for binary files (although it can be argued that there may be a "binary locale", but I do not think that the locales defined for iostreams provide a suitable interface for this). So I would say that writing binary operator<< or operator>> for iostream classes would be wrong.
Otherwise, you define a separate class for binary I / O (possibly reusing the streambuf layer to do real I / O). Since we are now talking about different classes, the above argument no longer applies. So now the question arises: should operator<< and operator>> read “text input / extract operators” or, more generally, “data input / extract formatting operators” for input / output? Standard classes use them only for text, but then there are no standard classes for inserting / extracting binary inputs / outputs, so standard use cannot distinguish between the two.
I would say that binary insert / extract is close enough to text insert / extract, that this use is justified. Note that you can also create meaningful binary I / O manipulators, for example. bigendian , littleendian and intwidth(n) to determine the format in which integers should be output.
Apart from this, these operators are also used for things that are not actually I / O (and where you don’t even think about using the streambuf layer), for example, reading or pasting into a container. In my opinion, this is already a misuse of operators, since the data is not transferred to or from another format. It is simply stored in a container.