Test setup:

The Gate is set to trigger a Single Energy Pulse on active Redstone. Short Redstone pulses sometimes won't trigger the action, even though the gate will light up to indicate the signal.
When the timer (set to 1 or 2 seconds) is running, the gate will either trigger on every pulse, or none, until the timer is turned off and on again. This can be reproduced with pulse lengths between 1 and at least 4 ticks, where 1 tick seems to have the highest probability of failing.
Changing the repeater setting / pulse length during a timer run does not produce consistent results, and it won't make it react to something it hasn't before.

I am using BC 7.0.17.

What Action are you testing with? Energy Pulser?
Could you try with a different action like Power a Wire?

It's not going away just yet (BC 7.0.19).
The Gate in the above picture is a Diamond OR Gate with each slot set to a Single Energy Pulse on active Redstone, so it should extract 8 items per pulse.
In cases where it would not trigger before, it will now extract only 1 item and still not trigger the "pump-style" Gate animation.
In cases where it would have triggered before, it will either extract 8 + 1 items in 2 separate stacks, or 8 items like it should.

This only applies to the Single Energy Pulse setting, the standard Energy Pulsar exhibits the behavior (for short pulses, of course) I described in the original post.

Adding an intermediate stage to the signal like Pipe Wire does not affect the behaviour of the Energy Pulsar.

Oh. Huh. I didn't think of that, actually.

Is it possible that

if (tick++ % PULSE_PERIOD != 0) {
    // only do the treatement once every period
    return;
}

in GateExpansionPulsar.java#L87 breaks on pulse lengths < 10 ticks?
That, and the fact that you randomize tick.

Spreading the workload like that is not an issue when you don't need absolutely predictable behaviour.
One solution would be to seperate the logic for the Energy Pulsar and Single Energy Pulse so the former can be used for non-critical applications where you just need a stream of items, and the latter for exact extractions with the caveat of potential lag spikes.