Learning codebases involves a significant amount of reverse engineering! You have to get into the head of the authors and make guesses about why things work the way they do.
You keep on asserting that, but what are you basing it on?
According to Wikipedia[1], "In 1990, the Institute of Electrical and Electronics Engineers (IEEE) defined (software) reverse engineering (SRE) as "the process of analyzing a subject system to identify the system's components and their interrelationships and to create representations of the system in another form or at a higher level of abstraction" in which the "subject system" is the end product of software development." It goes on to clarify that "Reverse engineering can be performed from any stage of the product cycle, not necessarily from the functional end product."
Further, "There are two components in reverse engineering: redocumentation and design recovery."
Are you arguing that the work here does not fit the definition or that the definition is wrong? In the latter case, could you please share your definition, and maybe even explain why it is superior to IEEE's?
We need a name for the phenomenon where a popularization of a term is more narrow than its original usage and then people who only encountered the popularized word insist that the narrow application is its only meaning.
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.
What does it mean to "have" "it"? You might have assembly. That's an "it" that you can "have". Plenty of people derive meaning from it. Some people, like the retro gaming people, even use the assembly as the "form preferred for modification" if they don't have the original source. How is inferring the intent of, say, dense uncommented C or dense CUDA much different?
This is just stupid semantic arguing. In the situations where you have assembly, its from getting it in some arcane way that is not supposed to happen. Building something to rip Nintendo roms for example. Looking at a codebase isn't reverse engineering.
