OpenGL – ortho Projection matrix, glViewport

Look at it practically. First, the fewer matrices you send, the fewer matrices you have to multiply with positions/normals/etc. And therefore, the faster your vertex shaders.

So point 1: fewer matrices is better.

However, there are certain things you probably need to do. Unless you're doing 2D rendering or some simple 3D demo-applications, you are going to need to do lighting. This typically means that you're going to need to transform positions and normals into either world or camera (view) space, then do some lighting operations on them (either in the vertex shader or the fragment shader).

You can't do that if you only go from model space to projection space. You cannot do lighting in post-projection space, because that space is non-linear. The math becomes much more complicated.

So, point 2: You need at least one stop between model and projection.

So we need at least 2 matrices. Why model-to-camera rather than model-to-world? Because working in world space in shaders is a bad idea. You can encounter numerical precision problems related to translations that are distant from the origin. Whereas, if you worked in camera space, you wouldn't encounter those problems, because nothing is too far from the camera (and if it is, it should probably be outside the far depth plane).

Therefore: we use camera space as the intermediate space for lighting.

This is strange

Nope. Fixed function was replaced by programmable pipeline that lets you design your transformations however you want.

I should create them in the opengl app and then multiply the vertices in the vertex shader with the matrices?

If you want to have something that would work just like the old OpenGL pair of matrix stacks, then you'd want to make your vertex shader look, for instance, like:

in vec4 vertexPosition; 
// ...

uniform mat4 ModelView, Projection;

void main() {
    gl_Position = Projection * ModelView * vertexPosition;
    // ...
}

(You can optimise that a bit, of course)

And the corresponding client-size code (shown as C++ here) would be like:

std::stack<Matrix4x4> modelViewStack;
std::stack<Matrix4x4> projectionStack;

// Initialize them by
modelViewStack.push(Matrix4x4.Identity());
projectionStack.push(Matrix4x4.Identity());

// glPushMatrix:
stack.push(stack.top());
    // `stack` is either one stack or the other;
    // in old OpenGL you switched the affected stack by glMatrixMode

// glPopMatrix:
stack.pop();

// glTranslate and family:
stack.top().translate(1,0,0);

// And in order to pass the topmost ModelView matrix to a shader program:
GLint modelViewLocation = glGetUniformLocation(aLinkedProgramObject,
                                               "ModelView");
glUniformMatrix4fv(modelViewLocation, 1, false, &modelViewStack.top());

I've assumed here that you have a Matrix4x4 class that supports operations like .translate(). A library like GLM can provide you with client-side implementations of matrices and vectors that behave like corresponding GLSL types, as well as implementations of functions like gluPerspective.

You can also keep using the OpenGL 1 functionality through the OpenGL compatibility profile, but that's not recommended (you won't be using OpenGL's full potential then).

OpenGL 3 (and 4)'s interface is more low level than OpenGL 1; If you consider the above to be too much code, then chances are you're better off with a rendering engine, like Irrlicht.