The Arduino core uses hardware Timer0 with its ISR (Interrupt Service Routine) for timekeeping. While delayMicroseconds() directly uses the value of the hardware timer, delay() and millis() are handled by the ISR. It will be called regularly.

If the ISR is getting executed during your measurement, then the execution time of the ISR will add to the execution time of your measured code. Thus you get a higher count occasionally.

To prevent this you can either deactivate all interrupts (via noInterrupts()) or deactivate this specific interrupt, either by stopping Timer0:

TCCR0B &= ~( (1 << CS02) | (1 << CS01) | (1 << CS00) );

or by letting the timer run, but deactivating its interrupts:

TIMSK0 = 0;

For details about this have a look at the datasheet of the Atmega328p, which is the microcontroller on the Arduino Uno.

As explained in the previous answers, your actual problem is not the accuracy of delayMicroseconds(), but rather the resolution of micros().

However, to answer your actual question, there is a more accurate alternative to delayMicroseconds(): the function _delay_us() from the AVR-libc is cycle-accurate and, for example

_delay_us(1.125);

does exactly what it says. The main caveat is that the argument has to be a compile-time constant. You have to #include <util/delay.h> in order to have access to this function.

Note also that you have to block the interrupts if you want any kind of accurate delay.

Edit: As an example, if I were to generate a 4 µs pulse on PD2 (pin 19 on the Mega), I would proceed as follows. First, notice that the following code

noInterrupts();
PORTD |= _BV(PD2);   // PD2 HIGH
PORTD &= ~_BV(PD2);  // PD2 LOW
interrupts();

makes a 0.125 µs long pulse (2 CPU cycles), because that's the time it takes to execute the instruction that sets the port LOW. Then, just add the missing time in a delay:

noInterrupts();
PORTD |= _BV(PD2);   // PD2 HIGH
_delay_us(3.875);
PORTD &= ~_BV(PD2);  // PD2 LOW
interrupts();

and you have a cycle-accurate pulse width. It is worth noting that this cannot be achieved with digitalWrite(), as a call to this function takes about 5 µs.

This a very partial answer. I do not know your requirements, whether or not PWM can do the job, etc... I just wanted to point out that you can make a pulse exactly 8 µs long with this:

#include <util/delay.h>
#include <util/atomic.h>

// Pulse PD3 (digital 18 on Mega 2560)
// for exactly 8 us (128 clock cycles @ 16 MHz)
static void pulse() {
    ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
        PORTD |= 1 << 3;
        _delay_us(8 - 0.125);
        PORTD &= ~(1 << 3);
    }
}

The _delay_us() function from avr-libc is actually cycle-accurate inline assembly. The 0.125 µs I subtracted is the time needed by the actual port writes: both the sbi and cbi instructions take two cycles (0.125 µs), but that delay should only be counted once. digitalWrite() should always be avoided in time-critical code.

The 242 µs delay between pulses would be harder to generate without PWM. A timer interrupt at 4 kHz seems like the simplest option, but it is not cycle-accurate.

Edit: here is the scope trace, showing a quite accurate timing: