The thing that ties cracking to the demoscene is that, as Trixter/Hornet states in the excellent documentary "Demographics: Behind the Scene"[0], copy protection itself is a creative process; you need to think about how the hardware works.
For example, one of the earliest copy protection methods - and one that still underpins a lot of today's copy protection - was to include intentionally-bad sectors on the floppy disks that you shipped. That's not something you'd normally even consider - why would you ever want to have intentional errors? And it makes even less sense to the non-creative mind when you consider that you can't just "write an error" - that's not how the common abstractions for disks work, and hardware is normally built in such a way that it's difficult to intentionally introduce an error. You actively have to go out of your way to misuse the hardware capabilities available to you in order to do so.
However, that very same difficulty in "writing an error" is also what made it such an effective copy protection method! Any traditional disk copying program would consider an error to be proof that your disks were corrupted, and many wouldn't even continue past the point of the error because it could lead to disk thrashing. Meanwhile, because you had much more control over the hardware back then than you do today, the copy-protected program could actually use the floppy disk controller directly to put in its own tests for detecting an error in a particular spot, such as reading the same sector multiple times and seeing if it got different data, or perhaps even by measuring the flux directly, and only proceed with the program if the error is there as it expected it to be.
You can't do these things using the standard INT 21 calls that DOS gives you, or even through the BIOS. (Actually, for many years PCs were considered useless for demomaking compared to other platforms such as the Amiga.) Finding a solution like that takes a creative mind - and conversely, so does working out how to defeat it. You have to know what your hardware can and can't do, or you have to work it out through experimentation. And as it turns out, you had to have exactly these same skills if you wanted to be able, say, do 3D on a system that has no floating point processor, or to be able to draw 4096 colours simultaneously, or to be able to arbitrarily draw to the overscan area of the screen, or any of the other things you might be able to figure out and want to show to the world what your chosen platform can do. And thus, cracktros were born.