OK, I think i've fixed this issue. And it IS a bug in Linux's network manager.
See, the network manager runs as part of the boot process (that'd be the 'S50NetworkManager' symlink) and brings up your ethernet interfaces. However, it does it asynchronously. This means that the network manager returns immediately, implying to the scripts after it, "OK - network's been set up." Actually, it hasn't, and the network manager is sitting there in the background getting on with setting up the network. Meanwhile, the boot scripts after it are running with the assumption that the network interfaces will be available, which is a race condition, depending on whether the network manager has gotten round to setting them up yet.
This is a horrible situation and a bug I'm amazed hasn't been fixed. One way of getting round it is to ditch the network manager and instead set up your interfaces by editing /etc/network/interfaces. Rather than do that work, though, I tried the ugly hack suggested in this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=486372
I added a 5 second delay ('sleep 5') into the beginning of the start function in dhcp3-server's init.d script, this giving the network manager ample time to get the network interfaces set up (although of course there is still no guarantee) - and it worked. Now, dhcpd succeeds on startup.
As detailed in bugs #486372 and #447442 on bugzilla.redhat.com, this is either a bug with network manager (it should block until its wired network interfaces are available), or with dhcpd (it should be updated to wait for network interfaces to become available, rather than just crashing out). It is definitely a bug of sorts, though.
If you want to measure the performance penalty, you would need to create an appropriate client/server setup. and run transfer tests to your liking.
But there would not be a performance penalty for additional IP addresses. There might be an increase in CPU usage if you have more than one MAC address configured or run the interface in promiscuous mode (likely, if you have a bridging setup) as the host would need to evaluate the entire traffic that is received on eth0, not being able to use the NIC's filtering on broadcasts and the "own" MAC address. However, the impact would be negligible in a correctly configured switched network - the switch will mostly forward only relevant traffic to the interface.
Best Answer
It should be as simple as taking the unwanted interfaces out of your mrtg.cfg file. Each interface should have its own set of lines with a unique identifier, so remove the lines you don't want.
If you're using some kind of script to generate the mrtg.cfg file, then you'll have to look to that. If you're using the stock
cfgmakerscript, you can apply an interface filter with the--if-filter=command; the filter is a perl-regex that defines the interfaces you want to include.