That seems to be a key difference between science and engineering. One likes to survey the field and insist that their paper offers something novel - no matter how big or small. The other just wants to do some solid work and get the results.
If you don't do the lit research part, how do you know you are getting results and not reinventing the wheel?
Maybe it's fine for an undergrad writing a toy expository paper in an educational setting, not contributing to anything real. But why should I read someone's thesis if there's no reason to expect it's not already covered in my textbook?
Not really. The point is that in research we want to generate and further knowledge. This is distinct from generating and documenting facts. If you don't link into the web of knowledge there is (implicitly: leave that task up to the reader) you are just documenting facts.
This is not academic. What did reading this Master thesis teach me? That two approaches perform reasonably (by what standard?) with a size trade-off. That's an excellent start but also leaves open many questions: Why these two approaches? Are there reasons to expect they are better suited than other approaches in the literature? Were these results expected? Can I expect them to generalize? Do they paint a coherent picture on the performance of different designs in various contexts or are they surprising?
A lot of this is about generality of the knowledge gained. As a mere fact ("Two implementations of two algorithms that solve one problem perform slightly differently") it's not very interesting unless I have that exact specific problem myself. If I do, I would still need to find the paper. But if it is linked into a wider web of knowledge ("In paper [X] it was found that this algorithm performs well on tasks that have something in common with our problem, paper [Y] and [Z] suggest that we should expect a trade off for small sizes. Generally nothing is known about what should be algorithms well suited to the problem at hand.") it allows me to reason about situations.
>> The point is that in research we want to generate and further knowledge. This is distinct from generating and documenting facts.
Hence the desire to constantly look for novelty in academic work. Engineers don't necessarily care about novelty, they need to solve a problem at hand for practical reasons. Documenting what they've done, how it performed, and what they learned (if anything) is still important to write down for others who may want to solve similar problems.
I personally find the quest for novelty often reads like some kind of desperate need to justify the work or to get it funded. Solid work can stand on it's own even if there's nothing new about it, while mediocre work seems to stand so long as it's go some element of novelty.
If I've already decided what method I want to use to solve a problem, finding a well-done implementation and documentation on it is all I really want. If I don't know what solution to apply to a problem, a survey that documents the various approaches and makes some comparisons is what I want.