I'm very reluctant to criticize someone like Jeff Doyle, but I'm reading that very same paragraph you mention, and I think he could have chosen his words better.
Remember that an OSPF router maintains the state of each its neighbors from its own point of view. So from R1's point of view, R2 transitions to INIT when R1 hears a hello from R2, not when R1 sends a hello to R2.
Quoting from RFC 2328:
On broadcast networks, each router advertises itself by periodically
multicasting Hello Packets. This allows neighbors to be discovered dynamically.
So even if R1's neighbor is down, R1 is still sending hellos on that broadcast network.
Here's an example from GNS3:
*Mar 18 14:36:55.615: %OSPF-5-ADJCHG: Process 1, Nbr 10.4.1.1 on Ethernet1/1 from FULL to DOWN, Neighbor Down: Dead timer expired
R1#debug ip ospf hello
OSPF hello events debugging is on
R1#
*Mar 18 14:37:53.255: OSPF: Rcv hello from 10.4.1.1 area 0 from Ethernet1/1 10.1.2.2
*Mar 18 14:37:53.255: OSPF: Mismatched hello parameters from 10.1.2.2
*Mar 18 14:37:53.259: OSPF: Dead R 48 C 40, Hello R 12 C 10 Mask R 255.255.255.0 C 255.255.255.0
R1#
*Mar 18 14:37:55.603: OSPF: Send hello to 224.0.0.5 area 0 on Ethernet1/0 from 10.1.1.1
*Mar 18 14:37:55.607: OSPF: Send hello to 224.0.0.5 area 0 on Ethernet1/1 from 10.1.2.1
*Mar 18 14:37:55.715: OSPF: Rcv hello from 2.2.2.2 area 0 from Ethernet1/0 10.1.1.2
*Mar 18 14:37:55.719: OSPF: End of hello processing
As you can see, even though R1's neighbor is down (due to hello timer mismatch), R1 is still sending hellos on that interface.