Does a large number of components will affect performance ?

It really all depends. The things that are going to affect performance the most in this type of situation are the monobehavior functions that get called every frame (Update) or even multiple times a frame (OnGUI). So if every single one of your components inherit from monobehavior and each have their own Update, OnGUI, ect, functions yes this is going to affect performance some. And even then breaking them out to child objects is not really going to help because you will still have the same number of calls to update ect every frame.

So how do you combat this? Generally with a mixture of, creating a careful inheritance structure to your classes and if needed a little bit of state based programming.

For instance for something like a player character object, You may want to create a component called something like Player or PlayerController or similar and use it as the main place where update and OnGUI are called for your player. It could perhaps inherit from your Seeker component, which could in turn have it's own instances of Char Motor and a class for interactions that are just generic classes that are not derived from monobehavior. What used to be in the update functions for these components could be renamed to more descriptive things and controlled more directly from within the update of your Seeker or PlayerController classes. This also can help cut down on message passing between components. Designing this way you could also make an NPC controller that also inherits from Seeker but perhaps does other things and doesn't have an instance of a generic input class. I hope this is making some sense, in general you are trying to compound a bunch of your components into one through careful inheritance and instances of generic classes that don't inherit from monobehavior. But even though you end up with one or two or so main components your code is separated into many files and reusable classes. Creating these long inheritance chains for complex objects is pretty common in many areas of game development. For example if you are ever working with the Unreal engine half the battle is studying the chain of inheritance that is already there and deciding where to break it and start writing your own subclasses. Designing these inheritance chains is the real meat of object orientated programming. A lot of folks around these forums talk a lot about object orientated design and think they know a lot about it because they have a bunch of gameobjects each with their own set of unique JavaScript components but thats really more of a behavioral programing approach then an object oriented one.

For your all sorts of components for GUI stuff you could use a more state based approach. Say each component implements a different menu screen or something. Instead of letting each one have their own OnGUI function and constantly checking whether or not they should be drawing somewhere inside of that OnGUI function you could instead take all that code you would put in OnGUI and rename it to a function like Draw. Then you could call a particular menu components draw function from inside of the OnGUI function of your PlayerController based on what menu state the player was in.

So this is a pretty long answer, but like I said in the beginning it really all depends on what you are doing. If you have have an object with 15 or so components but really only one 2 or 3 are controllers with updates being constantly called and the rest are just some sort of gui stuff that is just siting there waiting to be run in an OnGUI call, you are probably fine. If you have 15 components all with their own updates doing their own things you may want to rethink you design a bit. But then again if there are not very many complex things going on in your scene it could be just fine too. It really all depends on the project and situation.

Also don't take my comments above about behavioral programing too seriously. No one programming approach is always better then the other. Sometimes a quick JavaScript behavior is a better idea, sometimes a complex inheritance chain of C# classes is better. The best way to learn what works were is to keep designing things and trying out your ideas to see if they work.