Upon thinking about it... I think it's actually what I said to start - neither good nor terrible. Defining good and terrible code is easier than defining mediocre code, so we can do it by process of elimination. Mediocre code isn't terrible, but it's not good code either.

So, what is good code? Testable and well-tested, modular, isolated, easy to read, robust, performant...

What is terrible code? Well, the opposite of that, but generally there are some key indicators - code that breaks badly in edge cases, code that is impossible to read, code that entangles itself in a lot of other code, code that is hard to test.

So, mediocre code would be something that has some of the properties of good code, but is missing a few of the more important ones... maybe the tests aren't fully baked, maybe there are some inefficiencies, maybe it's a little harder to read than it could be, maybe it's not quite as isolated from the rest of the code as one might like.

The difference between mediocre and bad is the number of subpar things and their severity. If there are no tests, that's bad. If the code is horribly entangled with unrelated code, that's bad. If it's N cubed time in a place where we expect to handle large amounts of data, that's bad. If it ignores several common edge cases that will have really bad effects, that's bad.

It is subjective, but it's not entirely opinion, either.