Different use cases call for different performance vs. quality trade-offs.
In the viewport, rendering speed is of prime importance. When you're dragging vertices around, you don't need accurate lightning, or even reflections. What you need is that the vertex position reflects where the cursor is right now rather than where it was six hours ago. Blender lets you go down all the way to wireframe if you really need the frame rate, but usually one uses the OpenGL renderer. Instead of raytracing each pixel, you throw at it a simple math formula that ignores all the surroundings, but it still looks reasonable.
In the final render, you want photorealistic results. To do that, the Cycles renderer computes the color of each pixel separately. That takes time, but it lets you get things like: accurate reflections and refraction, lighting that doesn't go through walls, lighting that bounces off mirrors and even walls, fog... You can tweak that by setting the number of samples. Fewer samples take less time to compute, but the results are noisier. Blender can sorta do that at acceptable speed in the viewport, but it does so at reduced resolution (bigger pixels) and very few samples.
Blender 2.8 introduces the EEVEE renderer. It doesn't quite give you the best of both worlds, but it does look far better than the internal renderer that was in 2.7. But there's stuff that it cannot do. Accurate lighting is a process that really takes time, and there's no way around it. EEVEE lets you compute lighting in advance (very slowly), but that doesn't work if you want to bounce light off of things that keep moving around, and it does need you to set up where the samples should be taken from and at how many. You can fake accurate reflections by rendering the scene from specific points and then querying the renders from each pixel, but that only really works for small things or flat surfaces. And it also needs setting up. It can also raytrace reflections based on what's shown at the screen (much faster than using the scene directly), but that fails when stuff is behind a corner or just outside the viewing cone.
- Blender internal works well for modelling, but the results look nowhere near realistic.
- EEVEE can produce great-looking images really fast, but it can't handle things like dynamically changing global illumination, multiple refraction, or even curved mirrors.
- Cycles is the main selling point of Blender. It can produce photorealistic images, but it needs the time to do so.
- In the viewport, you want speed. Cycles is bad at doing things fast.
- In the final render (which is what the render image command is for), you want things to look perfect. And that takes time. You can configure Blender to use EEVEE for the final render - to cut down the rendering time at the expense of accuracy - but if you can spare a few minutes of waiting, you can get a still image that looks better than what even EEVEE can produce, and then - when you're ready to generate the data that you really need to be perfect, increase the number of samples even higher and then give it the time it needs.