I don't have SDL installed, so I couldn't run your code. However, from what I can see the problem is not the calculation of the rotations (not 100% certain if they do not contain any mistakes, but they look fine), but the object you are rotating.
The problematic line is this function call in your main function:
rotation(angleX, angleY, angleZ, v[i].x, v[i].y, 100);
What you want to do, is to rotate a cube, a 3-dimensional object, and draw it to your screen. But what you are actually doing is the equivalent of rotating a piece of paper (2-dimensional) with a drawn cube on it and printing this to your screen. Every point you pass to your function has the same z-value.
With the paper example in mind, let's go through your images and the effects you are seeing (take a real one and draw your cube on it, if you can't imagine it). Note that rotations always rotate around the coordinate origin (the point at x=0, y=0, z=0).
Rotation around the z-axis (second image)
This is like putting your finger onto the point where your coordinate origin is and starting to rotate the paper around this axis. Since your cube is not at the coordinate center:
int centerX = SCREEN_WIDTH / 3;
int centerY = SCREEN_HEIGHT / 2 + 100;
it is not only rotated, but also translated. The farther away your finger is from the cube, the larger the translations.
Rotation around the x-axis (third image)
This is basically like gluing the piece of paper to your fingertip (don't do that) and tilting your wrist joint so that your finger goes upwards. The paper moves upwards, and so does the cube. Additionally, the paper also gets tilted which has the effect, that your cube gets visually compressed in the y-direction since you can see less of the papers surface. In the extreme case, you would only see the upper side of the paper, degenerating your cube into a line.
Rotation around the y-axis (fourth image)
Same as the x-axis but tilt your wrist joint to the left instead upwards. So the cube moves to the left and gets visually compressed in the x-direction.
The solution should be obvious: Use 3d points by adding a z-component.
What you did with your cube is that you already manually applied a parallel projection to it before all other transformations. But the projection usually has to be the last step after all other transformations. I say usually since I can't rule out, that there are some fancy effects/techniques, that do it differently.
However, I think it might be helpful for you, to read at least some tutorials about transformations. Read for example those two:
They might be related to OpenGL, but the information you get from those two are universal. Make sure you read them in the order I linked them.
One remark regarding this part of your title: "(representing 3D in 2D)". Every "3d game" calculates a representation of your 3d scene in 2d since your screen is 2 dimensional. This is also true for VR. In VR you just do it twice, one representation for each eye, tricking your brain into believing you see in 3d.
using namespace std;. See this Stackoverflow question to understand why.