From the perspective of a C# developer, none of this is terribly ground-breaking, and some of it is downright idiotic.
"guard" appears to be a "not-if". Pointless. If I want not-if, I'll use if(!whatever).
Then you fail to understand its usefulness: if is a clear indication that it is a guard(!) and it is easier to read. Some languages have a unless statement which makes code easier to read but this is a statement specific for validating arguments.
"defer" is a clunky way of copying the "using" block from C#, but without requiring the code-by-convention IDisposable implementation. Useful, but could've been better. At least it has notable improvements over the status quo.
It is a statement that have uses but can make code much harder to read if used wrongly. The example in the article illustrates that well.
"repeat/while" is retarded and an unnecessary change away from well-known and accepted language conventions. This is the kind of convention that is actually worth sticking to, and Apple just broke it. "Nice job breaking it, hero."
Surprise! There are other programming languages than C out there, some of which use repeat ... while constructs. So it isn't breaking anything (well, Swift code but isn't that an Apple standard?).
"do" is a sign that their language parser developers are lazy and bad at their jobs, because they can't handle a set of curly braces as a start-a-new-scope delimiter. Fire these lazy bastards.
Easier to read...
"error" is a goto label. It also converts "do" into try, and "try" into assert(). I guess you've got to call it something, and if you make it too much like your competitor's language, people will be skilled across both! A travesty! And who's with me in thinking that "catch let error as FooType" is clunky as shit? It's as bad as VB. C# has this one right: catch(FooType error) ... and done.
Again this is something that makes code more readable. By including the fact that a routine can fail in the declaration a lot of problems can be avoided, the requirement of the try keyword on things that can fail is much better than having it hidden from the programmer. Yes going in the direction of explicit error checking have problems but those are IMHO preferable to the alternative (hidden data passing).
Protocol extensions are nice, and are probably going to be quite useful in keeping your code readable. C# has had extension methods for a while now, and they're quite useful. It's good to see that Apple is adding that sort of thing to Swift, as it can prevent a measure of code rot.
OptionSetType is the same as .Net's FlagsAttribute. Not special, but, again, a nice addition. It even goes a step further and adds easy bitwise comparison handling for you. Again, good on Apple for taking an existing good idea and making it better.
What does it do that Pascal's set type doesn't (except being much more verbose)?
And the last item appears to be an improvement to what .Net developers would call "interop". Any improvements are welcome, as interop is universally a pain. It will never be "right", but it may be tolerable.