Be careful - your post mixes two different types of compatibility.
Compatibility between new software and old OSes is something Apple cares very little about, broadly speaking. In Apple's view, you should be on the latest OS, and if your hardware doesn't support that then you should get new hardware. This goes especially for iOS. For example, Xcode out of the box won't even let you target an iOS version older than 8.0 (late 2014), although you can target macOS down to 10.6 (2009). And Apple usually doesn't backport security updates to previous major versions of iOS, and only goes two versions back (two years) on macOS.
So neither of the examples in your quote are too surprising. At the time the article was written, Apple didn't care about iOS 3 or macOS 10.6. If you want to support 'ancient' OS versions, that's your problem.
On the other hand, Apple cares more about compatibility between old software and new OSes, though not nearly as much as, say, Microsoft.
For example, the post mentions garbage collection. Objective-C garbage collection was never supported on iOS (2008) and was officially deprecated in 2012 with the release of ARC; Xcode stopped supporting it in 2014, but macOS continued to support existing binaries until Sierra (2016). Now, this is arguably a pretty aggressive deprecation schedule, but ObjC garbage collection had relatively little adoption throughout its life, and had a significant maintenance burden. (Among other things, in the past it was impossible to use ARC libraries in an GC app, meaning all of Apple's system frameworks had to use manual retain-release; AFAIK though this was later fixed, some time before support was removed.) In any case, Apple added a tool to Xcode that could automatically migrated most GC code to ARC.
On the other hand, 32-bit binaries are still supported in macOS even though macOS has supported 64-bit CPUs since 10.4 (2005!) and required them since 10.7 (2011). I guess there was more adoption than GC, and Apple didn't want to break stuff. As usual, iOS is more aggressive: there are rumors support for 32-bit binaries on 64-bit devices will be removed in the next minor 10.x; iOS has supported 64-bit since 2013, though it currently still runs on 32-bit devices. Even so, that's >3 years for what in most cases is just a recompile.
Deprecating Swift would be massively more disruptive than either of those, as migrating off it would require complete rewrites. The only analogy I can think of is Carbon, which Apple famously refused to port to 64-bit, requiring Adobe applications to have their UI layer rewritten for Cocoa. But Carbon was meant to be a transitional API since it was released with the very first version of OS X in 2001. It would be 6 years before the transition to 64-bit started, and as I said, 32-bit binaries are still supported today.
The only possible reason Apple might be more aggressive with a hypothetical Swift deprecation is its relative newness and the resulting relative scarcity of existing code (but there's still a fair amount). But then, Swift has already been out for several years, and it's clearly not going to be deprecated anytime soon, given the current level of enthusiasm by Apple and others. If for some odd reason Apple decided to deprecate it, it wouldn't be for several more years, at which point there would be even more existing code.