That's one reason for the larger value B-E resistor: less bias current gives less bandwidth in the output transistor(s), and therefore less prone to oscillation. (We're talking ~10MHz of bandwidth, well in excess of what the op-amp can deliver -- the transistors don't need to be that fast, and it can hurt to run them that fast, for this reason.)
Note that SPICE models often fail to model transistor phase shifts correctly:
I built the circuit on the left, which oscillates. The simulation shows it is stable. I had to modify it, to the circuit on the right, to get the simulation to oscillate. Unfortunately, the parasitic components are about 10x larger than what is realistic for the circuit. I am left to conclude there is some additional phase shift or delay in the real transistor(s), which is not present in the provided models (which I obtained from ON Semi, IIRC), or which SPICE cannot model at all*.
*SPICE contains two infamous hacks to approximate real phenomena:
1. A PN junction, in forward bias, stores charge. This charge must be built up before the junction "turns on" (forward recovery), and depleted before it "turns off" (reverse recovery). SPICE models this as a dependent capacitor with a dependent current sink, so that the V(I) curve is logarithmic (following the Shockley equation -- the static diode curve), and the stored charge behaves like a battery (charge is ~exponential with voltage). A dependent capacitor
cannot model forward recovery, because it's always capacitive, and the capacitance increases as it's being charged, whereas forward recovery is more like a resistor that decreases as charge is stored. Reverse recovery is modeled reasonably well at least, but diode losses are usually underestimated (recovery loss is significant in real converters). But even more tricky is
where charge is stored: it's not stored uniformly in the junction: it diffuses through the semiconductor. You can apply a short forward-bias pulse, then hold reverse bias, on a diode; if it's the right kind of diode (the doping profile is involved, as well), the reverse recovery transient will not move softly, but explode open in a fraction of a nanosecond: this is called drift step recovery (aka Grekhov diode). The short forward-bias pulse dumped a wad of charge into the junction, which happened to diffuse out all at the same time, then suddenly, poof, the junction goes open-circuit! This sort of thing is, in principle at least, impossible to model accurately in SPICE, because it's a bulk semiconductor thing.
2. Transmission lines. This is a much less lengthy description, okay... Transmission lines: you put waves in one end, wait a delay, and they come out the other end (and reflect back and forth, depending on impedances). This is a hack because SPICE uses variable timesteps, which means what waves entered the TL are propagating at a nonuniform rate (that is, not at a constant distance per timestep). It's not as simple as spinning around a circular buffer. Most simulators simply restrict the maximum timestep, so the steps become uniform inside the TL -- which means no shortcuts can be taken during slowly changing times, and the simulation crawls. (Or it may be more complex than that, I haven't looked. It 'feels' like this is the case. It may simply be that it's doing extra math to resolve the variable timesteps, and that increases the overhead significantly.)
In any case, these are components which cannot fundamentally be realized in SPICE: SPICE is the domain of matrices, where there is no speed of light (or, if there is, it's infinite), where transfer functions have no real delay, only poles and zeroes. You can make approximations, but only that; an RLC transmission line approximation needs dozens or hundreds of stages, or the SPICE transmission line hack requires lots of internal memory** and runs slow. One must keep these limitations in mind, when one wishes to construct some more unusual simulations (you know, like things in reality).
**Okay, to be fair, this was back when you were lucky to run SPICE on a mainframe with 64k+ of core. Now who here remembers what "mainframe", "64k", and "core" were
Tim