Reverse engineering is not only deriving source code from an executable. Reverse engineering is figuring out what resulted in any given solution. This could be the source code that resulted in a given executable, or it could be the design decisions, considerations, and reasoning behind some given source code. You can go even further and reverse engineer those requirements to guess at the problems they were meant to solve, and so on and so forth. Reverse engineering is literally just going backwards: from machine code to source code, from source code to ideas and thoughts, from ideas and thoughts to the inciting problems or even more fundamental things. You can also reverse from further in the other direction, i.e. reverse a binary from a desired output (superoptimization!), reverse the desired output from the result of a calculation involving it (hello password cracking), etc.

Though password cracking is not necessarily the best example, some (very bad!) hashing algorithms can actually be reversed that way. Figuring out the reverse is, reverse engineering. You would reverse engineer the algorithm to figure out how to create a collision that way. Same as superoptimizers sort of reverse engineer the behavior you want to come up with a very efficient implementation. I'm using the term reverse engineer a bit loosely there but you get the point. It has nothing to do with source code really, you can just as easily reverse engineer physical objects. Or artwork. Or the psyche.

So yes, you can reverse engineer source code to understand on a deeper level how it works. Sometimes reading it over once or twice is enough for this, sometimes even reading the API documentation or observing behavior is enough, but sometimes you have to do a bit of thinking and/or testing to fully understand it.