To the best of my knowledge the main use case for width is to align the text when viewed in a terminal or an editor with a monospace font. The second use case is padding the output with '\0', space, or some other character to satisfy some width requirements. It is somewhat limited in addressing the first use case because, as pointed out by Tom, it's hard to solve this problem in general (but it's possibly to have decent approximations), but it works if you restrict your inputs which is what often happens in practice.

> If no vendor feels that their customers would benefit from a field-width specifier, then there simply won't be any implementation of field-width, and therefore there will be nothing that needs standardizing.

That is the worst possible option in my opinion because it will create a portability nightmare similar to the one that currently exists with printf extensions.