does anyone know why micros() isn't using this 1MHz ticker?
What 1 MHz ticker?
It is using the 16MHz clock of the processor.
Several boards are based on MBED, which adds a ridiculous amount of overhead to micros(). For instance, on rp2040, micros takes about 4us to run, even though it eventually just returns the contents of a counter maintained by hardware.
What boards are you referring to. Also since you did not say which processor I mistakenly assumed it was a typical Arduino UNO or Nano.
It's a GIGA R1. I hadn't thought to mention that as this is the GIGA R1 category.
us_ticker_read() is a macro
/* Macro-optimised form of us_ticker_read */
#define us_ticker_read() (TIM_MST->CNT)
I'm using it because it is significantly faster than micros() and was wondering why micros() wasn't simply an alias
expanding on my earlier reply, micros() calls mbed::TimerBase::elapsed_time(), and it seems that MBED takes great care to insure that reading the time is atomic and monotonic - a process must NEVER EVER get an earlier time than another process that asked for the time first.
So...
micros() calls mbed::TimerBase::elapsed_time()
which does CriticalSectionLock() around mbed::TimerBase::slicetime()
which does CriticalSectionLock() (again) around ticker_read_us()
which does core_util_critical_section() around update_present_time()
which does something with 64bit us counts in a "ticker_event_queue"
// (and those lock functions aren't very simple, either.)
I'm not impressed.
It certainly seems to me as though MBED, as an embedded OS specifically targeting ARM microcontrollers, ought to support a more direct interface to hardware timers that are likely to exist. Perhaps it does, but the Arduino code fails to use it. It all seems so unpleasant that I'm not inclined to investigate further. 
@westfw thanks for taking a trip down the rabbit hole. I've been using the us_ticker_read() macro for some time without issue, but then I don't exploit threading directly.
If I see any issues I'll report them here