Generalities
The rule of thumb “lots of plugins slow down a site” is a very blunt instrument and is perpetuated by those who don’t understand how plugins work so they pick something easy to demonize.
Yes plugins can slow down your site but it doesn’t have to do with the quantity it has to do with the quality and what they are trying to accomplish. I could write a single plugin that would bring a site to it’s knees (if there were a reason for me to do so) and it would be worse than 50 other well-written plugins. Of course people write plugins all the time that will bring a site to its knees because they don’t know any better.
I guess the only truth to “lots of plugins slow down a site” is that when you have a lot of plugins it’s more likely that you’ll catch a bad one.
Specifics
So let’s talk more specifics. Plugins use “hooks” which are bits of PHP code that run a certain points along the execution path and they can either do something or filter a value or both. WordPress starts calling hooks earlier in its efforts to compose a web page and generate HTML to send to the browser and continues calling hooks almost until it finishes running for a given page.
Depending on which hooks a plugin uses it might be called only on certain pages, in the “background” or even almost never. Some hooks only work within the admin console. Some hooks only work within certain pages of the admin console. And some hooks are called by the internal psuedo-cron system. OTOH, some plugins can load extra CSS or JS files and each of those files slows down performance because of Web Performance Rule #1.
If you want to get a feel for what hooks are called on each page consider using the “Instrument Hooks for WordPress” plugin I wrote for the question “Where Can I Find a List of WordPress Hooks?” Here’s a screen shot of what the plugin shows in the footer when used:
But just knowing the hooks won’t help you know for sure if there is a problem with a plugin. You could call a plugin 100 times and calling it could be negligible compared to another hook call that adds a WHERE clause to a SQL query that could bog down a site that has more than a few hundred posts. Or it could do an HTTP call to another server. Or it could flush the rewrite rules on every page load. The list of sins goes on.
The only real way to know for sure it so audit the plugin’s hooks by reviewing the source code or better running it through a debugger like PhpStorm+XDEBUG.
Your Own Plugins
Don’t worry about how the code is organized for purposes of performance; worry about what your code does. Optimizing a frequently run SQL query buy leveraging the Transient API (See: Presentation about the Transient API) would be far better for performance than merging the code of 10 plugins into one.
On the other hand, do consider organizing your code for other reasons. I think a long list of plugins can create psychological distress for a lot of users; they see a screen like this, get overwhelmed and just want to simplify things:
(source: mikeschinkel.com)
Yet on the other hand sometimes users can be overwhelmed because one plugin does too much. For example I felt that way with the GD Star Rating Plugin. After trying it on a project (and worse, trying to hook it to get it to do what I needed) I decided to toss it out on it’s ear.
So some people (like me) will often prefer lots of small tight plugins that each do one thing and do it well (it would be nice though if WordPress would support a grouping feature kinda like how iPhone iOS 4 lets you group apps in folders.)
(source: mikeschinkel.com)
Anyway, hope this helps.