It's a tradeoff between power consumption and the needs of software. Software needs a high resolution time source that reliably ticks along at a constant rate. From a hardware perspective, there is a strong desire to turn off PLLs to save power when the clocks they generate are "not needed". Unforunately, hardware and software have different definitions of when "not needed" is. Hardware also wants to be able to change the clock speed for clock domains (like a given core's clock rate), but hardware doesn't have any interfaces to tell software exactly when these clock rate changes occur, so software has no way to compensate for the discontinuities in clock rate. Ouch.
The Linux kernel community brought up these requirements with the large CPU vendors at Kernel Summits dating back to the early '00s. To say that the kernel community is frustrated at the state of time keeping in mainstream CPUs is understating it. Software (especially the kernel) is under constant pressure to provide accurate, high resolution and reliable timestamps. That requirement will never go away, so the hardware folks need to figure out how to make an interface that works in the presence of aggressive power savings in modern CPUs. Honestly, if the CPU had a get_time instruction that returned seconds and nanoseconds that was as fast as the TSC, software would use it in an instant (although I'm certain that some hardware vendors would manage to screw it up with BIOS bugs on random motherboards).
