Here, Swift (it seems) makes an implicit suggestion that a developer keep their error handling tight and bounded. If you don't, the language softly penalizes you with the need to add keywords to be explicit about changed flow. Go does something similar in eschewing try / catch error handling for a single panic / recover system and very explicit error handling via return values (this was a very intentional design to address what the language creators perceived to be common failure modes in code they were maintaining at the time in other languages, see here [https://go.googlesource.com/proposal/+/master/design/go2draf...] for details). In Go, it's harder to make a certain category of mistake, but at the cost of the user writing more code to handle the error path (and assuming the implicit cost that every line of code could introduce a different mistake).
Every language feature in every language we use (static type declaration vs. implicit types with casting, variable predeclaration vs. implicit creation on first write or read, GOTO vs. function calls vs. try/catch vs. continuation passing, etc.) makes these tradeoffs.