Swift exposes protocol-oriented programming in a way that you won't find in Objective-C or Java. While Swift has "C family" roots like those other languages, there are some very deep areas of the language that you will not have experienced before, and this is one of them.
Swift certainly provides nice ways of calling Objective-C libraries, and a lot of work has gone into seamless interoperability between the two languages. With the right amount of @objc sprinkled about, you can indeed use Swift as "Objective-C with a nicer syntax." However, that is a deceptive façade. It's only one subset of a much larger and very different language, and it's the subset that includes perhaps the most exceptions for compatibility reasons.
"Optional requirements" are one such compatibility feature. The spelling "@objc optional" isn't for the compiler's benefit--it has no need of the "@objc" and (as far as I'm aware) its implementation in Swift actually has no dependency on Objective-C at all. Rather, this spelling is meant to communicate to you, the writer, that you're using a compatibility feature implemented only for the sake of Objective-C interoperability. Put another way, the reason you're required to write "@objc" isn't because Swift is so similar to Objective-C that it's borrowing its features, but because Swift is so different from Objective-C that, other than for interoperability purposes, certain Objective-C features wouldn't exist in Swift at all.
Swift's tentpole goals are safety (specifically, memory safety), performance, and expressiveness. To make the language a worthwhile contender, it adopts ideas that are either absent in other languages or much less emphasized because they've been bolted on later in their evolution. These would include features like optional types (introduced fairly early on to beginners), protocol-oriented programming (more difficult for beginners and a very deep feature with surprising results even for the experienced user), and (soon) ownership (intended to be an advanced feature). Even features that have counterparts in other languages can be quite different. Strings, for example, are Unicode-compliant by default and exposes an API for manipulation that explicitly discourages indexing into them. Mathematical operators have different orders of precedence than in Java or Objective-C (matching Go instead of C).
Chris Lattner likes to say that Swift is actually more complex than C++. The Swift Programming Language, by necessity, offers only a basic primer on each topic. After that, numerous books are now available for in-depth study. Personally, I've found Advanced Swift to be indispensable. Past that point, there are numerous resources to be found online for specific topics in Swift programming. WWDC videos and other talks can be helpful. The archives for these forums are also a good resource; they contain in-depth discussion both from the perspective of the end user (Using Swift) and the language designer (Evolution), and they're now easily searchable.