I think a core tenet of Swift is "progressive disclosure of complexity".
The features you described ("if ... case ... let ... where ...") may feel strange, but you don't have to use them at all! I would say each of those serves a useful purpose (variable binding, pattern matching) and can be mastered over time. Personally, these features improve my experience writing Swift and enable me to write cleaner, more understandable code.
This is in contrast to the for else Python feature you mentioned, which seems like a somewhat discouraged language feature that's more confusing than useful.
If you don't like a feature in Swift, you can propose a change. Proposals go through an open review process so the community can discuss and give feedback.
Maybe making a programming language with C instead of with obj-c or anything else will be a better idea.
C is simple and Go is simple by adding package, interface and concurrency upon C.
Go attempts to reduce the amount of typing in both senses of the word. Throughout its design, we have tried to reduce clutter and complexity. There are no forward declarations and no header files; everything is declared exactly once. Initialization is expressive, automatic, and easy to use. Syntax is clean and light on keywords. [...] And perhaps most radically, there is no type hierarchy: types just are, they don't have to announce their relationships. These simplifications allow Go to be expressive yet comprehensible without sacrificing, well, sophistication.
The goal of the Swift project is to create the best available language for uses ranging from systems programming, to mobile and desktop apps, scaling up to cloud services. Most importantly, Swift is designed to make writing and maintaining correct programs easier for the developer. To achieve this goal, we believe that the most obvious way to write Swift code must also be:
Safe: ... Fast: ... Expressive: Swift benefits from decades of advancement in computer science to offer syntax that is a joy to use, with modern features developers expect. But Swift is never done. We will monitor language advancements and embrace what works, continually evolving to make Swift even better.
It's clear that the languages try to solve different problems: Go has no type hierarchy while Swift has protocols, generics, etc. Swift needs to interact with Objective-C for app development.
Useful topics for discussion are how Swift could better fulfill its principles (or how specific language features violate these principles). But saying that Swift should "be a different language" is not so useful.