The alternative is to just write the same conservative solution for ten years. Then you are just as medioker programmer after ten years as when you started.
For instance: say you have an app with 30 different ViewControllers, and you need them to respond to the same notification. Sure, you could go back and refactor every one to subclass from another class that inherits from UIViewController - but then you need to make that for UITableViewControllers and UICollectionViewControllers, and potentially any other new view controllers that come along if your codebase ends up lasting for years.
Or, you could make one class category that method swizzles the viewDidAppear method to add the notification handling in immediately. Every class that inherits from UIViewController will now respond to that notification.
Oh, I read your link. So you add more behavior to it, not override it completely.
By that link's definition, then yeah, it's basically monkey patching.
Sometimes the quickest or even the most elegant solution isn't necessarily the "best" one. Best being a subjective term, I would say it depends on what you need from your code over time and with whom.
The classic analogy is with young musicians. Just because you can put a fancy ornament in or play real fast doesn't necessarily mean you should. Sometimes it's best to play something simple, so long as it's just the right something simple.
And what would you call my mindset, which can be summarized as "what cool features I can use to express the problem and it's solution in a simplest way"?
Remember, copy pasting is also very simple solution to many common problems.
New developers (less than 10 years professional experience) seem to become fascinated by "cool" language features that let them do unintuitive things and then approach problem solving with a mindset of "What cool tricks can I do to solve this?"
Instead, the experienced developer will always approach a problem with "What is the simplest way to solve this problem?"