This is one of those core decisions which defines the character of a distribution of an operating system, which has a sensible default, but most people don't use it.

So what are the consequences of the two different options?

Basically this choice feeds into a number of other decisions, so lets look at them and see what happens.

Software Packaging

The first thing that it affects is software packaging.
Packages go into a single repository in an install once (or Rolling Updates) system, whereas when you start to get near to the next version of a pulse based system,
you have to look at every package and decide how to transition it to the next version,
and if it needs to go into the old repository, the new one, or both.

This is a lot of work, and results in masses of programs being ditched just because something has changed in a way that is incompatible with the previous pulse.

Rolling Updates

Every operating system has a system of rolling updates, so they can send out security updates, and new versions of software.
As can be seen from some of the disasters with updating government computer systems, things can go seriously wrong, and software can stop working, or start behaving differently with even relatively small updates.

The more things you update at once, the more chance for something really serious to go wrong.
If you are using a pulse methodology, you are maximising the chances of one or more important pieces of technology suddenly stopping,
as most of the testing is done after you have published the new version of your operating system.
Another problem is that your rolling updates don't move the repository to the next version automatically, but the longer past the release date of the next pulse you delay,
the more incompatibilities and the greater the likelihood of the update not working.

If you use install once with rolling updates, any incompatibilities appear as soon as the change goes into the repository, making you much more reactive to changes that break things.