"100% accurate" is a bold claim. Do you mean "accurate by definition", i.e. we should define "sequence" in terms of what PySequence_CheckNew returns?
Any Python code that uses isinstance(obj, collections.abc.Sequence) or a type annotation of obj: Sequence already defines sequences as something that subclasses or registers to abc.Sequence. It will conform by 100% to those semantics.
Static type checkers are still an optional tool for people who want that sort of thing. Quite a popular tool, sure. But discouraging duck typing would be a very big change to the status quo. Perhaps the proposal should start with that, rather than put it in a caveats section?
This is a much more philosophical question. We're not actually discouraging duck typing.
It might sound like a "big change", but de-facto, any code that currently requests a Sequence in its type annotation will not lint correctly with classes not inheriting from Sequence. Any code that checks isinstance(obj, Sequence) will return False even if the class perfectly matches the semantics.
Remember, abc.Sequence is not a protocol, it is an ABC. Look at the current situation, try passing a "sequence-like object" to random.sample() and you'll fail on the isinstance check. Pass a mapping-like to os.environ and you'll fail as well. These fail even if you don't use the "optional" type hint, and if you do use, half of the standard library will not work with duck typing if you don't actually register to the relevant ABC. You can't really say duck typing is encouraged if the standard library no longer fully works with it.
Either way, the discussion about duck typing is a little irrelevant, all we're doing is basically giving a faster alternative for isinstance(obj, Sequence) and isinstance(obj, Mapping) which are frequently used. What we meant by talking about duck typing is that the current PyMapping_Check calls everything that has __getitem__ a Mapping, while we call only things that are isinstance(obj, Mapping) a mapping, which matches both isinstance in Python and type annotations. If someone wishes to support duck typing he can choose not to use the function. Again, this is 100% accurate to the current Python semantics.