At just a basic level: 15-ish years ago, 3D rendering APIs used what is called the "fixed function pipeline". Texture mapping, 3d-to-2d projection, and so on were limited to the specific functions implemented in the hardware of the video card and exposed by the 3D API you were using.
The programmable pipeline requires you to define some programs called "shaders" that run on the graphics card and replace the previous fixed pipeline functions.
Example: Say you feed a bunch of geometry information into the API (a list of vertices, faces that use those vertices, coordinates for textures, etc). The "vertex shader" receives 3D vertex coordinates (and possibly other values) and needs to output 2D screen coordinates. The hardware calculates which screen pixels will actually show which part of which face, and passes some coordinate information to a "pixel/fragment shader". The basic job of that shader is to read texture, color, and lighting information and decide what color should be output to the screen for a specific pixel (replacing the functionality of the lighting and texturing functions that were used in the fixed-function pipeline).
I think that three.js adds another level of abstraction on top of the actual graphics APIs.
Coming from a CS background, with a few years "in industry", I started by reading about the history of computer graphics, read some fixed-function 3D graphics tutorials, built a few toy programs, then moved to the shader pipeline, and built a few more toy programs with the things that I learned. Read theory, experiment to see how it maps to practice, refine your understanding, and then go back to reading, if necessary.
If I'm remembering correctly, I mostly ended up using http://www.opengl-tutorial.org/, liberally supplemented with Wikipedia articles and random mathematics articles, as necessary. (obviously, this isn't focused on WebGL and Three.js, but the core concepts apply. It might make more sense to go for tutorials in the ecosystem you'd like to learn, rather than learning one system, then having the time and cognitive overhead of learning to map the concepts to a new system).