But that's exactly the point, do the scripts really need to lug about support for stuff that maybe one, maybe two people actually use?...
:-) This topic is perfect for /. because of the complete lack of scope.
When you refer to "scripts", what level/layer are you referring to? I don't even think there is a well defined naming convention for that (ex. something like an OSI model with respect to configuration of hardware).
Given the networking example...
On the GUI level, there are loads of interfaces, many specialized, to aid in configuring the network. Some of them are protocol-specific, such as various VPN utilities, kppp and other ppp utilities, dial up interfaces, and a bunch of wifi ones too. Many of those are somewhat modular, with a backend/libs, command line interface, gnome/gtk interface, qt/kde interface, and possibly others (curses, xfce, tk, etc). That said, there is a primary target within this cadre: Network Manager and all its cousins.
On the other end of things, within the kernel, there's loads of drivers and standardized ways for those to interface with the various kernel subsystems. Those drivers necessarily have a wide variety of options... that's kinda the point. The vast majority of those can be compiled into the kernel, built as modules, or not built at all. This layer is fairly well defined as there is a clear separation of user space and kernel space; this ends at the first layer that provides a user space API (and this could be considered to constitute two layers... kernel space and user space of that... think OSI layer 1 and 2).
On that kernel level (similar to OSI media layers), I don't think we have a problem. This is, at least partially, due to the monolithic nature of the kernel and it's management by a benevolent dictator. A few comments here have mentioned support for old hardware, but I don't think they are referring to the drivers themselves nor the kernel... they're likely referring to something further up in user space. IMO, if the question is posed here, the answer is "No, Linux is not becoming too complex".
On the top end of the GUI side, I'd also argue that, "No, Linux is not becoming too complex". Yes, it can be a quagmire of various utilities at times, and some work better than others, but that *should* be fine. Hell, that's the only way to quiet those that complain about supporting all that old hardware - just snip it out of the GUI utility or hide it in advanced areas. I would never want to enforce a rule that these must all go through some specific middle ware, though that's really the part we should all be talking about.
So... the middle. This thread referenced "/etc/network/interfaces". That does NOT exist on all distributes (ex. redhat based systems don't have this). Personally, I like /etc/network/interfaces, but it's a good example of fragmentation of "standard" ways/interfaces to configure the kernel networking subsystem. Is it bad that debian and redhat both do it different? IMO, the "becoming too complex" question would imply that this is NOT bad, since this has been this way FOR A LONG LONG LONG TIME, and I'd agree that this amount of differentiation is ok and even good, but this could easily be argued is and firmly into the grey area.
The part that I have very large concerns with is what is currently happening with the low-level just above kernel... specifically, systemd and its related parts. Networking is an example here, as one of its goals is to provide one unified/common way to configure the network.... but doesn't that already exist!?!? It's called the kernel! On the other hand, maybe it will prove to be a useful shim? The fact that a single framework is going in above the kernel, which some direct ties to the kernel, and is casting a very wide net in terms of things it is, or can, control (logging, network, dhcp, login, init, sessions, mounts, consoles/vte, timedated/ntp, devices/udevd)... we'd better hope and pray it's designed well cause everything and the kitchen sink will soon have direct dependencies on the interfaces it's implementing.