I think the conclusion is:
1. It's not TECHNICALLY wrong to mix C and C++ if the resulting code performs the task required.
2. In a C++ educational situation, it is probably right to require that code that can within reason be solved in C++ _is_ solved in C++. There are situations where 5 lines of C becomes 15 lines of C++, then perhaps the C solution is actually more appropriate - sscanf() can be such a case, particularly if the input format is not designed for reading via C++ [e.g. it's got various formatting within the input itself, that scanf can accept and validate, but C++ cin doesn't without a fair bit of effort].
Where I work, we mix third party drivers written in C with our OS's C++ code - because we are not going to spend 6 man-years rewriting a graphics driver providing OpenGL to the client software - by the time that is finished and working correctly with good performance, the graphics processor is probably "old". But that is of course large chunks of C code mixed with other large chunks of C++ code - mixing it with a few lines of one, then a few lines of the other is not quite the same thing.
But both C and C++ are tools - they come in the C++ toolchest - so it's "ok" to use any of the tools. Part of learning to program is of course learning how to use which tool - just like a carpenter needs to learn when to use a broad chisel, a narrow chisel, a knife, a drill or a saw - they all do useful things, and you can SOMETIMES use one in place of the other, but one is most often better than another.