The tomllib PEP addressed a particular bootstrap loop: you need a TOML reader to build a TOML reader library.
But, AFAIK, writing doesn’t have this loop. You don’t need a TOML writer to build a TOML writer library. And once you have that library, it can be used as a dependency. (And yes, dependencies are tricky, and sometimes you need to do things like the flit/flit-core split. But IMO, that’s solvable without stdlib help.)
For tomllib’s externally visible behaviour, there were about one or two design decisions that weren’t answered by doing the one most minimal correct thing.
A TOML writer, especially an extendable one, has many such decisions to make.
tomllib is done: it has a well-defined scope, and it fills it. By including it in stdlib, we’re actively discouraging the development of other TOML readers (except ones that expand the scope significantly – like those paired with a style-preserving writer).
I don’t think we want to do that for TOML writers.
(I recommend reading “The Dark Times” in Hynek’s post on attrs vs. dataclasses as a cautionary tale.)