It is, and there are several such packages. Looking through announcements on this forum: Frame-it v1.0.0: Framing for Theorems, Definitions, … – Customizable, Beautiful, Seamless and Codly v1.1.0: beautiful and easy code blocks, for example.
Regarding the second question – rant incoming: I treat my own packages (which are all 0.x so far) like cargo and try to avoid breaking changes in patch version changes. It’s important to remember that Semver is only a convention; if we as a community de facto conform to that interpretation, that becomes what Typst package versions mean. Likewise, if we use three-component versions but don’t adhere to semver, there’s no tool inherently stopping us from doing so (but let’s hope we don’t go there).
And since it’s tangentially relevant: package versions (currently) can’t specify pre-releases, etc., so Typst does not implement full semver anyway.
Typst’s stance on compatibility is (currently) more strict anyway: you have to always specify full package versions. What would be a “non-breaking change” to a programmer may be a breaking change to an author; let’s say changing some font size. Suddenly your pages look horrible because a paragraph takes an extra line. So you could argue that Typst ignores Semver’s definition of compatibility anyway.
</rant>
To come back to your question more directly:
I personally adopted that rule, and while I don’t know about others’ intentions, the Typst ecosystem broadly feels like this. I’m not sure if we really need to formalize this, since I’m not sure what practical difference it would make. Two reasons against it I can see would be 1) package authors are open source authors, and I wouldn’t want to force this rule on someone who feels it’s a nuisance to them, and 2) if a package is unpredictable with breaking changes, that may impact its adoption anyway, so I think that creates enough regulation on its own.