Or 12 channels, or 16, or ...
Seriously, this has been discussed before, and the answers remain the same.
The current layout works on a 800 pixel wide screen without scrolling (I wish we could forget about those low resolutions but apparently there are still quite a few people around with 1024x768 or 1024x600 screens...).
The answer would not be to change the arbitrary number 4 to the arbitrary number 8 (and nope, I'm not going to copy&paste all the required code, it's bad enough as it is), but to rather create the general tab content dynamically rather than loading it from a template, but that would require all the code there to be rewritten.

If he's having the same problem as I did, it may be the navigating between tabs that he's annoyed with. I refer everyone to this FR:

http://bugs.openmpt.org/view.php?id=111

I will consider this feature request once the plugin settings are on their own tab, since then we won't have to care about scrolling one thing but not the other anymore.

why not just have how many channels u want in the general tab just be an option in the settings so u can have as many channels as u want???

Because, once again, this would require the entire code to be rewritten anyway. The current "code" is just four copypasted resources - having a variable amount would mean converting the resources to dynamically generated elements. Plus, I'd like to get rid of the tabs and use a scroll bar instead, but that won't work nicely as long as the plugin box is below that, because it would just scroll along. As said, I'll tackle that once the plugin box is somewhere else (which will hopefully be the case in OpenMPT 1.26)

I've been working on this a while ago, and while it works in general - it's slow. It's not my code that's slow, it's just that creating WinAPI controls is slow in general, especially if an application allows the system to style the controls for XP/Vista/7/8/10 looks (like OpenMPT does). It takes about 1-2ms to instantiate a control, which may not seem much at first. But there are 15 controls per channel, so switching to the General Tab of a module with the maximum amount of channels (127) would take 3-5 seconds every time.

Clearly this approach won't work. Maybe we can reduce the number of controls to only create as many as there fit on the screen (but this has negative implications for blind users relying on screen readers), or avoid recreating the controls everytime you switch away from the General Tab.

Plus, I'd like to get rid of the tabs and use a scroll bar instead"

Excactly my thought when I saw this topic. This wouldn't be solved with just adding 8 channels to the general-view, but what Saga said here would. So why not just do that, remove the tabs completely and make a scrollable mixer-view with all the channels laid out - that also makes layout-symmetry sense to the pattern-view as well. I'm guessing this is exactly what you're going for Saga? Excited for the farthen day this change will happen :D

That's what the patch above does, but as said - initializing the General Tab is awfully slow once you have a few dozen channels. It's not really practicable in its current state. Maybe lazy loading will do the trick...

On top of the slowness, a module with 127 channels consumes about 900 GDI handles with this strategy. This really doesn't scale well with the default limit of GDI handles per process being 10000 (could maybe load 10-11 modules with so many channels before OpenMPT essentially becomes unusable).