Upon more thought, I’ve identified exactly what sig fig feature is missing in the built-in format specification. Including the details here in case anyone now or in the future is interested.
The built in formatting can always display numbers to a specified number of sig figs just using exponential mode directly. E.g. f'{123.456:.3e}' gives 1.235e+02. '.pe' will format to p+1 sig figs.
The built in formatting will also always display a number to a specified number of sig figs using the #.pg mode. The downsides are (1) the inclusion of the # means that mantissas with no fractional part will have hanging decimal points and (2) The user has no way to coerce fixed point mode.
More on point (2): specifically, according to the -4 <= exp < p rule (a) it is impossible to display floats less than 0.001 in fixed point mode while specifying sig figs and (b) It is impossible to get fixed point mode while specifying fewer sig figs than there are digits to the left of the decimal point.
Point number (b) says that it is impossible to pass any formatting string that will convert the float 123456 into the string '120000'. I imagine this was the intention behind requiring exp < p for fixed point mode. The original authors didn’t want the possibility that float format would look like it’s rounding (as opposed to just truncating) the floats passed in. Of course the float formatting DOES do rounding all the time, f'{1.77:.1f}' gives '1.8', but I can see the argument for not rounding “above the decimal point”.
So in other words, built in formatting is comfortable with sig figs as long as the least significant digit is at or below the decimal point.
Including sig fig formatting would certainly make it possible to pass a formatting specification that converts 123456 to '120000'.