Exceptions have the same problem as return codes in that you need to be careful to leave things in a consistent state if a function throws an error. RAII can help to some extent in both cases, but doesn't magically enforce that your classes and data structures are internally consistent.
My experience has been that error paths have a way of getting things into inconsistent states, and then you're in trouble regardless.
Checking return codes is annoying but if you're wanting to write robust software, your code needs to be in some way aware of every possible error path.
Copying short non-overlapping chunks of memory is common in a lot of workloads (think manipulation of short strings) and it does happen in tight loops where an overlap check with two additions, two comparisons and two branches is a comparable amount of work to what memcpy() does.
Why should I have to manually implement memcpy() for small sizes when I know the memory won't overlap?
I don't really see what your peer did wrong. Sometimes you need to see the actual implementation to understand how different approaches work out. There are definitely plenty of times I've started implementing A, then realised it doesn't work out that well.
Assuming that people will make mistakes writing code isn't distrust, it's just common sense.
If someone is a good developer, I trust their first cut of code will be well thought out. I don't assume that they considered all corner cases or found the best design or written things in a way that makes sense to other people on the first try.
Things go downhill if people start taking code reviews personally, but then I don't think the real problem is code reviews.
I'm sorry, but breadth-first-search is a simple and fundamental algorithm and straightforward to write if you understand the concept and have decent coding skills. You're just visiting a level of the tree at a time: stick each level in a list, iterate over it, and append the next level's nodes to the next list. There's no trick to it.
Not being able to do write a basic BFS algorithm suggests a) you didn't do any interview prep and b) whatever you've been working on hasn't involved any non-trivial algorithms.
It doesn't mean you're a bad programmer but if you can't answer a basic BFS algorithms question I wouldn't trust you to touch code with any non-trivial algorithms in it.
My experience has been that error paths have a way of getting things into inconsistent states, and then you're in trouble regardless.
Checking return codes is annoying but if you're wanting to write robust software, your code needs to be in some way aware of every possible error path.