I once dealt with code that looked like this pattern (sorry for the giant vertical size of this post):

  DO_F() {
    A;
    B;
    C;
    D;
    B;
    C;
    D;
    E;
    F;
    A;
    B;
    C;
    D;
    G;
    H;
    I;
    J;
    A;
    B;
    C;
    H;
    I;
    // a bunch more
  }

So I suggested, "hey perhaps you should break this into functions" and got back:

  DO_F() {
    A;
    B;
    C;
    D;
    B;
    C;
    D;
    E;
    F;
    A;
    state.a = a;
    state.b = b;
    // ... for other state
    return DO_F2(state)
  }
  DO_F2(state);
    B;
    C;
    D;
    G;
    H;
    I;
    state.a = a;
    //...
    return DO_F3(state);
  }
  DO_F3();
    J;
    A;
    B;
    C;
    G;
    H;
    I;
    // a bunch more
  }

When I suggested blocks such as B; C; D; or G; H; I; could be functions, and perhaps a loop could be useful too, the guy looked at me like I was trying to do voodoo and got really defensive about how that couldn't possibly work.

I think that is what the OP meant by bulldozer code...

Not only that, the purpose of refactoring isn't simply for reuse, but also for readability. If you break out chuncks that aren't reusable, but enhance the readability of the code then you've likely improved the code.

Given the choice between reusability and readability I'd say that readability should usually win (although it is a false choice).

I would contend that if you're having code readability issues, it'd be better to fix it by sprucing up your whitespace and comments, instead of saying "Well, let's chunk it into more functions" and have method(), which returns method1(), which returns method2(), which returns method3()...

Chunking for the sake of itself doesn't seem like a viable strategy to me.

When you add a new-line or two into a section of code, you're usually saying:

"These two blocks of code do something different"

Thats what is normally called a method. If it's only for one class then by all means make it private and name it well, so the caller remains readable.

Chunking out in more functions is good in itself, because there's usually a well defined interface for what can get in and out of a function.

Whitespace and comments can suggest that some pieces of code don't interact that much, but chunking into functions lets the compiler prove it.

I agree that that strategy's pretty feeble, but IMO it's still better than e.g. a thousand-line function. If nothing else it forces you to break out the parameters explicitly, instead of just having a thousand lines of intermingled state transitions.

Fully agree and I want to add, that it is also a requirement for writing good, simple, small unit tests. Clean code means, a function should only do one thing and that's the thing you can test.

I find this is one of the things I struggle with the most. I definitely "refactor" code by moving it to a subroutine sometimes purely for readability's sake. I also try not to stress out about how reusable something might be until I actually NEED to reuse it. Otherwise it often seems like "premature optimization" trying to generalize a routine that I'm not even sure will ever get used anywhere else.

In my experience, the drive to make things reusable from the start ends up delaying projects to a point where they might just not get done.

I also refactor for the sake of readability (and urge my co-workers to do the same). Of course, this might mean I'm a bad programmer and I shouldn't ever get 6 levels deep in logic in the first place...