In other words "I'm incredibly lazy and want someone else to take a handful of complex topics and magically turn them into a pamphlet for me."
Nothing you are asking about can be properly understood via infographic. In fact, many of the most popular and well respected "minds" in the iOS/Mac development community are outright failing to understand the concepts since they are derived from higher level languages and these guys have been stuck in the doldrums of C/Obj-C for decades. Basically, the people most likely to dive into this new tool are completely out of their depth. The people most likely to be able to explain it are focused on other things, typically far more academic than most people will find interesting. Someone who spends a lot of time fooling around in Haskell, or O'Caml, or even Clojure and Scala will provide more insights than most people in the Apple development community.
But, for the sake of completion, here is the skinny:
Not one single thing in Swift is new. Nothing. It's all derived. And it's a pretty nice concoction in the end. Closures are especially not new. Many languages have had them for years. They sometimes come with different names and slight variations on just how much state they enclose, but, that's not important. The fact is that they aren't new and you can find enormous amounts of info about them generally and specifically all over the web. You may choose to start with https://en.wikipedia.org/wiki/Closure_(computer_programming)
Optionals are proliferative also: https://en.wikipedia.org/wiki/Option_type
In fact, wikipedia is a great place for all your questions to be answered (or just read the damn Swift book, it's not nearly as long as you think and you don't have to delve into the whole thing to get these important key elements covered.) Swift on Wikipedia: https://en.wikipedia.org/wiki/Swift_(programming_language)
Even with that information it's likely you will miss what's important about these changes, but, they can nearly all be summed up with one word: predictability.
Optionals and everything associated with them vastly improve predictability. Their existence will further enhance a programmer's life when people stop obsessing over compatibility with Objective-C and focus on new work in Swift natively where you will be using optionals as little as possible, focusing on idioms where it's totally unnecessary (hint: it's entirely possible to write software with no concept of null or any kind of invalid address at all. Swift helps get close to that end while retaining compatibility with legacy software/libraries, partly with Optionals.) That aside, pointers are still accessible within Swift. You merely have to be very deliberate about it. Most of the symbols that will litter your code that accesses them will have the word "unsafe" in them for good reason.
An enhanced type system improves predictability about what data will be accessed at any given time.
Lack of nil message destinations, and hell, far fewer "messaging" concepts in the language improve predictability about what code will be executed at any given time.
Closures coupled with the (eventual) proliferation of immutable value types will provide a far greater predictability for first class functions, or code as data. As much as possible, state of the program should be in the runtime, not arbitrary data structures. These constructs help make that possible, while falling far short of enforcing it (unfortunately, for that you can take a look at languages like Elixir/Erlang.)
Predictability means fewer invisible programmer errors which means higher quality software before the software is even executed in the debugger. Tools to restrict what code can actually do are far superior to runtime testing, even if they are not quite enough to totally eliminate the need for runtime tests. Many of Swift's features and behaviors revolve around improving static analysis for this sake. As a developer, you have to go out of your way to cause a segfault/EXC_BAD_ACCESS type error in Swift, and there will be obvious syntactical elements helping to call out that you did that (presence of ! is always a code smell and should be given great thought when using it, hence the choice of an exclamation point.)
As for compatibility and people doing things their own way, I have been updating an iOS app that I wrote with the first Xcode beta that supported Swift. I have had to make very few changes. Of course, Swift is a very new, very actively developed language. It is broadly advertised by Apple that changes should be expected. That is a very good thing. We want a tool to adapt quickly at the beginning where compatibility is extremely unimportant. But, if it makes you feel any better, your built iOS apps will have no problems running even after Swift is changed since each app includes the runtime libraries.
Specifically regarding people doing things their own way: obviously! It's a new language with concepts that many—probably the vast majority—of the typical work-a-day hacker type writing user-facing software have never encountered before despite existing for decades. Programmers are notorious for not having any concept of the history of the tools they use. I laugh every time someone talks about Ruby like a new idea, considering it has been around almost as long as the World Wide Web.
If you aren't prepared to participate in a tumultuous storm of change and uncertainty, then just stay away from any truly new language or platform. It's not for the faint of heart. Things will break. Ideas will have to be deeply considered. There will be far fewer knowledgable, authoritative sources to tell you what you really should do versus the many people who will spout the first nonsensical interpretation that comes to mind despite not actually understanding the thing at all.
In other words, it's a ton of fun and there is no place here for oversimplification. The opposite is needed.