In the context of an electronics lab I think it would be useful to measure clock jitter. Apart from that, no idea.
With an MCS at hand, it becomes possible to perform measurements that would otherwise be impractical, generally due to needing an entire bench full of equipment made of unobtanium. You soon develop the mindset of trying to convert almost any signal parameter into an analog pulse train by adding simple circuitry to convert the parameter(s) of interest into pulse characteristics.
Let's take your clock-jitter example. Pulse analyzers are very good with short-time events, but less good with longer term events (their clocks are accurate only over relatively short windows). Since jitter is, by definition, the irregular timing of individual edges, we would then want to convert each edge, both positive-going and negative-going, into a pulse. There are many ways to do this, most of them needing less than $5 in parts.
The neat thing about working in the pulse domain is that you can get away with some really primitive pulse conversion circuitry, not even caring much about the component values. This is true simply because we tend to care about differences between pulses, the relative measurements, rather than the absolutely correct values.
One of the hardest things to do in many analog circuits is to correctly analyze noise in multiple domains (voltage, current, amplitude, phase, harmonics, short-term vs. long-term, etc.). Moving things into the pulse domain can simplify such characterization. I once had to characterize extremely low frequency noise on a 2KV DC power supply: The equipment being fed by the supply was exhibiting long-term semi-periodic irregularities, and every part of the system had to be examined to find the cause. My job was the power supply.
The first obvious thing to do was to scale the output voltage down and feed it to a 6-digit DMM. But the DMM itself wasn't stable enough over the long times we were interested in (hours to days). Even the 12-digit meter in our calibration lab wasn't stable enough for long-duration measurements.
What I did have access to was a simple voltage-to-frequency converter (VCO), a well-controlled oven, and high-precision voltage reference that WAS stable for days and even years at a time (even inexpensive references are generally more stable and far cheaper than the expensive instruments needed to measure them). I put the VCO into the oven, let it stabilize at a temperature a bit above ambient, fed in my precision voltage reverence, routed the VCO output to a simple pulse converter (also in the oven), and let the MCS run for a few hours. I got a very tall and skinny Gaussian distribution of pulse times that represented the stability of the pulse conversion circuit.
I then fed in the supply and took another few hours of data, and got another Gaussian distribution (I used the narrowest timing bins the MCS could provide). The neat thing about Gaussian distributions is that they provide a mathematically simple way to extract meaningful characteristics from huge amounts of data. I first normalized the distributions, then subtracted the reference data from the supply data, and got a distribution that reflected the instability of the supply.
For the few hours data I took, the result was barely a wiggly line barely distinguishable from zero. Were a variation present, I would expect the DoG (Difference of Gaussians) to have one or more distinct humps of its own. I repeated the experiment for both the reference and the supply for a full day each, and got nearly the same low-level result: The power supply was not the source of the data variations!
The only possibility that I was wrong would require the time-domain instability of the pulse conversion circuitry, the MCS, and even the voltage reference to PRECISELY match that of the supply under test: Not likely at all, unless you include an infinite number of parallel universes, in which case it is certain to occur in one of them. But not in our universe.
In today's world of cheap, fast, wide ADCs with almost unlimited sample depth, tricks such as the above are needed less often, and the MCS market has dwindled away accordingly. One unfortunate result is that technicians and engineers have become less familiar with domain conversions in general, especially quick & dirty ones in the lab, as well as the statistical analysis chops needed to make sense of the results.
Not that I'm complaining! I did the above while I was a technician at a company that made control systems and instrumentation for commercial and military nuclear power plants. When I went to college, I majored in Computer Engineering (CS + digital parts of EE), and today I make a nice living applying some of those old tricks in the software domain, to make nasty sensors and touchy control systems play nice.
A primary key for me has been knowing how to transform between domains: From voltage to frequency, from edges to pulses, from whatever you can't easily measure or analyze, to things you can. To know when you've done the conversion correctly (by creating and performing tests that yield unambiguous results), and to detect when it is no longer correct.
That's why I'm an engineer: I get to apply a world of tools to solve nasty puzzles, and I get to do it every day. Learning a new tool, and using it correctly, keeps me jumping out of bed every morning eager to attack my next problem. My favorite problems are the ones that kick my butt and make me feel like an idiot, for I know I will be less of an idiot when I finish!