To quote from the strict issue:
[…] turning julia programs that are semantically valid, but undesirable for other reasons (e.g. using ambiguous syntax that should have arguably been disallowed, but we can’t for backwards compatibility reasons) into errors.
So yes. One of the problems that strict addresses, is that valid Julia programs can contain mistakes. As some aspects of the language are more prone to silent mistakes than others (e.g. unintentional shadowing), restricting these aspects is intended to reduce silent mistakes. In my example, fabulate(y) is a mistake that would be prevented by such an annotation.
As for the python example: Yes, this concrete example causes a runtime error, but that’s immaterial. A Python or Julia program that throws a runtime error is not automatically semantically invalid. After all, it has a well-defined and clear computational meaning that just happens to result in an error.
Further, you don’t have to scroll far to find examples of Python code that doesn’t type check but does not throw runtime errors, e.g.: typing — Support for type hints — Python 3.12.4 documentation , the point being to catch logic errors in the code.
The set of Python programs that type check is a strict subset of the set of valid Python programs. Just as programs that conform to strict mode Julia will be subsets of valid Julia programs.