There are two important ideas to pick up here, I think. First, functional programming prefers a reduction-based model of computation: the whole program text represents the current state of the program, and a "step" of computation corresponds to simplifying ("reducing") the expression in a well-defined way. Second, `call/cc` adds a novel reduction rule that behaves a bit like function application, but looks a bit backwards. (`shift` and `reduce` then generalize the basic idea, but use the same machinery.)

In detail: Consider a program `fib 2`, which simply computes the third Fibonacci number and then exits. We can define `fib` like so (using Haskell-y syntax, which I find a little lighter for this purpose):

fib n = fib' n 0 1

fib' 0 a b = b
fib' n a b = fib (n - 1) b (a + b)

If we run this program, what do the individual steps look like?

print (fib 2)
= print (fib' 2 0 1) -- Substitute the definition of fib
= print (fib' (2 - 1) 1 (0 + 1)) -- Substitute the second clause of fib'
= print (fib' 1 1 1) -- Simplify - and + (technically, this is two steps)
= print (fib' (1 - 1) 1 (1 + 1))
= print (fib' 0 1 2)
= print 2 -- Substitute the first clause of fib'
= ()

This isn't just an analogy; this is exactly how an unoptimized interpreter could fully implement a simple functional language. There's no need for an actual call stack when evaluating this program: the program text itself describes "what to do next" (which is the point of a call stack).

Now, what does `call/cc` do? Well, remember what function application does: we take something like `(\x. FOO) A` and substitute `A` into `FOO` where ever `x` appears, no matter how deep into the program it is (unless it's shadowed, i.e. not the same `x`). We could write this as `apply (\x. FOO) A` if we wanted, although by syntax rules we know that the first value in a call is the function to call. (The capitalized names could be entire other expressions, whereas `x` is just a variable name.)

Similarly, if the whole program looks like `A (call/cc \x. FOO)`, we substitute `\y. A` into `FOO` wherever `x` appears (unless it's shadowed)`. It's a weird kind of function call, where the function is nested inside `call/cc` like normal, but the argument is everything outside `call/cc`. And since `A _` has got a value-shaped hole where the `call/cc` was, we know that if `FOO` is going to use it, it needs to provide it a value -- hence why we substitute `\y. A`, not just `A`. (So we have to fill the hole with the new variable name `y`.)

print (call/cc (\x. x 42))
= (\x. x 42) (\y. print y) -- `\y. print y` is equivalent to `print`,
= (\y. print y) 42 -- so I'll elide this expansion next time.
= print 42

This example seems kind of useless -- call/cc did nothing! But what if we had more values to return than just `42` -- what if we had a whole bunch of things, and we wanted to run the same processing for all of them?

print (call/cc (\x. x 42 >> x 101 >> x 0))
= (\x. x 42 >> x 101 >> x 0) print
= print 42 >> print 101 >> print 0

(`>>` is just a Haskell operator for sequencing, like `;` in C or Java.)

Now we've replicated the rest of our program based on each of the three values returned by the inner function. It's like we've bifurcated (trifurcated?) our program into multiple independent programs that continue from where the original program left off. (You might know that `fork` in Linux returns a different value depending on whether you're in the original process or in the spawned child process. This is very similar!)

But what if we don't want to do everything in our program multiple times? What if we just want to do some of it for each value, but join everything back together at the end for some final processing? Well, `shift` and `reset` let you do that. The `shift` operator slots in where `call/cc` was, but you now get to choose how much of the rest of the program to replicate by placing a `reset` somewhere else in the program. You can wrap the whole program in `reset` to get the same behavior as `call/cc`, or you can scope it to a smaller portion:

(reset (print (shift (\x. x 42 >> x 101 >> x 0)))) >> print "Done"
= ((\x. x 42 >> x 101 >> x 0) print) >> print "Done"
= (print 42 >> print 101 >> print 0) >> print "Done"

(We definitely didn't want to print `Done` three times, right?)

None of the program's behavior needed call/cc or shift / reset. They're fundamentally rewriting rules that let us give such a program a different form. Sometimes the forms we can achieve with call/cc are more readable or provide better modularity. Sometimes they don't (so we shouldn't use them!).

Shift and reset let you write your own coroutine system like it was nothing, though, so it's certainly not without merit :)