I have 100+plugins in my server. But I just use about 20% function of them. That means many variables and functions are meaningless for me. If all plugins are merged into one plugin, then hooks will only be triggered once.......Will this improve code execution efficiency?  Many IF are required of course.  HOOK and IF, Which is more efficient?

IF, but consolidating 100+ plugins isn't really worth it. You'd constantly be having to repair it almost every wipe, a situation that will drive you batty.

This is a great question. I'd like to take a step back and address the broader concern, which is, what are the risks of using publicly available plugins vs privately made/modified ones. There are a few risks that come to mind.

1. Unused feature code could refer to a part of the game that Rust changes at some point in the future, causing compilation failures at that time. The impact is that the plugin needs to be updated, but that could have been avoided if that feature code was not present. This risk can be mitigated at least two ways. First, the developer could distribute multiple source files, depending on which features people want to use, but it would be up to the developer to make or use a system that allows easily building the separate files from the true source. I'm not aware of anybody doing this, and multiple popular plugin distribution sites don't allow multiple files. Second, the plugin could have compilation flags at the top of the code file, which the server owner could edit to hard disable certain features, but the server owner would have to change those flags every time the plugin is updated, so perhaps a framework such as Oxide could provide a means to define compile time flags in a config file for persisting those preferences (the plugin can't do this itself since it would need to be compiled first).
2. Unused feature code could incur a performance cost. For example, hooks may be subscribed but effectively do nothing if a config option is set or the player doesn't have permission. The impact is that there is some overhead on the framework side and plugin side to process the events when not needed. Well optimized plugins can solve this by unsubscribing from hooks when not needed, such as when a feature is disabled in the config, or more dynamically, if no entity/player/object is currently present which needs the event at the time. In the worst case, where the plugin cannot easily tell whether the hook is needed, such as if it depends on the presence of players with permission, the developer can add a config option to hard disable the feature for the server owner to use at their discretion.
3. Unused feature code may have bugs which unintentionally modify the game. In other words, more code equals more risk. This can be mostly mitigated at compile time using flags or alternate source files, as mentioned in #1.
4. Lastly, multiple plugins subscribing to the same hook may be inefficient contrasted to one plugin having all the code. This was the original question this thread. I'm not sure of the exact impact of this as it is difficult to measure. In general, the performance cost of plugins comes not from overhead of having hooks called, but from expensive code running inside the hooks, so categorically consolidating hooks is unlikely to result in noticeable performance gains. Furthermore, consolidation can result in subtle behavioral differences, such as the operations getting called in a different order; cross-plugin-communication code that is introduced did to resolve conflicts may also not be easily transposed. All in all, I think this approach creates too much of a headache for anything but trivial use cases, so it's not worth it.

I too have roughly 100 plugins and extensions on my server and have no idea of how much resources of each of them i am using at any one time, But  with a "maxi" plugin that encompasses all the functions of all of them apart from being unrealistic would  complicate error checking when there are conflicts between the various parts . there is also the complication of changing the function of one part of the plugin ie: when the "gather" function, or "smelting" values need to be changed to satisfy one or more server owners , the change may or may not affect the function of another part of the plugin.