Very simple: Because there was room for an address and it improves performance a lot. Or as the manual puts it:
It is important, however, for the programmer to realize that the simplest method of programming (using sequential drum location for succeeding instructions) causes the machine to waste a large amount of time waiting and searching.
To start with, the 650 is not a load store architecture, as that would imply multiple registers, but an accumulator machine. Further, it might be useful to keep in mind that it's still in between a punch card computer and a computer as we know it today. We tend to always look at it as a CPU with a memory stored program, as now canonical, but its operation relies as much on the plug-board programming it had in addition.
Back to the question:
The 650's main storage was a drum with 50 words of 10 digits (plus sign) per track (band) and 20, 40 or 80 tracks. An instruction consisted of a two digit opcode and a 4 digit operand address. Of course they could have left the remaining 4 digits unused, or use it to encode the address of a second operand, making it a two operand machine, except that would have required a more complicated and expensive logic.
Using them to store the follow-up address improves things on several levels:
First it saves on the need of a separate incrementer for the program counter: only a load circuit is needed.
This in turn also implements jump instructions without any further effort.
On the software side, it allows many strategies to use this chaining for simplifying code and/or creating logic otherwise hard to implement.
And last but certainly not least, it did offer a great way to improve performance to the max, as the instructions could be spread out in a way to have the next always ready when the current one is done.
The last point is (as always) quite obvious when doing the math (*1). The drum rotated at 12,500 rpm; that's about 4.8 ms per turn, or 9.6 µs per word. Each instruction can, as usual, be described by the time it takes. For simplicity this can be done in word time (which equals 9.6 µs). Even the most simple instruction like an add will take 3 word times. So if we assume just the instruction timing (for simplicity), then the machine won't be ready to read a follow-up instruction until the fourth word thereafter. Placing the next instruction in a consecutive location would therefore add a whole rotation before it could be read and executed. That's 4,800 µs compared to zero when spacing the two sequential instructions three words apart, making it like 16 times slower than it could be.
Now, if it were that simple, they could have just put in a skew of 3 on the hardware level when addressing words as instructions (*2,3), but it isn't. Not only do instruction timings range from 3 to 17 word times (*4), but access also depends on the place the data is stored. Almost every instruction addresses some data (which the first address is meant for). Since data are stored on the same drum, and all heads are aligned, it means that an instruction has first to wait for the according data to come by, then execute and then fetch the next instruction. So there are two access timings (waits) to be incorporated into each instruction layout, plus its execution time (*5).
Optimum program structure means staggering instructions and data in a way around the drum that minimizes wait times for the data cell to come around and the next instruction to follow. And we are not talking a few percentage plus or minus, but up to 50 fold slower - as it may degrade a single word access to a whole drum turn.
In fact, a case can be made, that including the address of the next instruction is exactly the same case as for including the data address, as both are random access operations within the same framing of a memory access. Thus both should have the same freedom of determination within the program context.
Reducing that to an implied next address as of the following word is a simplification that's only free in a system with zero (or next to zero) access time.
*1 . In fact, the manual spends a whole section on what it calls "Optimum Programming".
*2 - And adding an incrementer for the PC.
*3 - But then again, this skew would also screw the access of the very same words as data ... not cool.
*4 - Plus exceptions like Table Lookup with its very own timing issues.
*5 - It gets even more complex due the fact that the accumulator adheres to drum timing, so execution time also relies on the instruction in question residing on an even or odd address. Also instruction search and data search can be in parallel if the circumstances are right.
