Supporting that makes sense to simplify the use case so that people don't have to write JavaScript for simple changes, but that doesn't imply they'll replace the JavaScript API with a purely declarative API there.
The difference between that and the traffic modification API is the threat model. The third party were to compromise uBlock Origin's servers, they would have a frightening amount of power over millions of machines because uBlock Origin essentially self-modifies; it downloads new rules for what should be blocked. So that breaks the security guarantees Chrome wants to provide; they can't say that the lock icon on a website means anything if a Chrome extension is allowed to arbitrarily modify traffic back and forth as a man in the middle on the last mile and Chrome web store maintainers haven't looked at the source code it's running.
I don't think there's a similar security threat for cosmetic changes.
The difference between that and the traffic modification API is the threat model. The third party were to compromise uBlock Origin's servers, they would have a frightening amount of power over millions of machines because uBlock Origin essentially self-modifies; it downloads new rules for what should be blocked. So that breaks the security guarantees Chrome wants to provide; they can't say that the lock icon on a website means anything if a Chrome extension is allowed to arbitrarily modify traffic back and forth as a man in the middle on the last mile and Chrome web store maintainers haven't looked at the source code it's running.
I don't think there's a similar security threat for cosmetic changes.