Sometimes I see how Unity programmers use one script that inherits MonoBehavior for almost the entire project. The so-called "Update Managers". All scripts are subscribed to the queue for execution, and the manager runs all functions, and after execution removes them from the queue. Does this really have any effect on optimization?
Based on this article which your link has a link to, having an "update manager" does indeed have a positive impact on performance when compared to using Unity's Update method. The gist is that if you implement Update in one of your classes, Unity has some additional overhead in calling Update; it doesn't run quite as fast as calling a method yourself, such as saying myObject.Update(). So if you're calling Unity's Update on 10,000 game objects per frame, that additional overhead becomes noticeable.
If you explicitly call your update-type methods from a "manager" class -- rather than letting Unity call the "magic" Update methods -- then you can avoid the additional overhead that comes with using "magic" methods.
But keep in mind that the performance penalty of using Update will only be noticeable if you have a lot of game objects in your scene that all implement Update. Game objects in your scene that don't implement Update won't have an effect. It would be good practice to remove the Update method that Unity adds to all new scripts if you're not using it though.
In short, unless you have a huge number of objects in your scene and you are running into performance problems, I wouldn't worry about it.