I think this is probably best described by stating the bad practices it would seem to be trying to avoid. I can remember the old days when these were common practice. But with modern 'dev ops' tools being so easy to use these days I doubt they are seen anymore.
Live code fixes. (Run and Build stages are joined) A bug is reported, I fix it on my dev machine, build locally and ftp the new dll/exe onto the live box. Copying it right over the top of the existing one. No check in to source control. My dev box is the only place the code is stored, if another dev does the same with another bug, the first bug is reintroduced. No roll back is possible
Live config changes. (Run and Release stages are joined) I go on a live box and change the config manually with notepad/vi and restart the app and it picks up the new settings. Again no central storage of the config, no backing up the old config, no documentation. If the box goes down the changes are lost, if I have multiple nodes they all end up with different configs.
No central build. (Build stage is ill defined) Although source control is used, the build is done locally from whatever version happens to be on that box at the time. Although the release is static, you cant tie it back to a definite version of the code. Local differences, such as what libraries are installed and global settings, like paths and the registry all effect the final release. So what works this time, might not work next time.
One more related to no central build
No storage of releases. (Release stage is ill defined) The build is done and deployed to live. But the binaries are not versioned and stored. The question of 'what version is live' is difficult to answer and rollbacks/re-deployments rely on backups of the live machines rather than deploying 'from scratch'