There's a fair bit of UIKit-parity that's still missing, which forces you to create a ViewRepresentable class and do the UIKit bridging yourself (this ranges in complexity, but can definitely present significant challenge depending on the task). This becomes more frequent too for lesser used Apple platforms (watchOS and tvOS).
Another place that's lacking that the author doesn't quite dig into is that SwiftUI has no concept of cell re-use at all. The Lazy UI components (stacks, grids) will _delay_ their initialization, however, nothing actually ever gets re-used. So if you're working with a layout similar to Netflix, every time you scroll left/right/up/down, new cells are being created and are loading more image data into memory. With UIKit, cell re-use is a foundational concept that all devs should be utilizing, so it's a bit of a headscratcher that something like this is still missing from SwiftUI by now.
To top it all off, as Apple does get SwiftUI up to spec, they are completely resistant to releasing support libraries (or anything along those lines) - so rudimentary UI features/modifiers/etc. that get added years later will only ever support the latest version of iOS and forward. This makes it much more restrictive to work with, as most apps are targeting at least 1 year back and not only the latest major version of the OS.