If you meant one file for CSS per media target, and one javascript file, and one HTML file, then yes, that would be faster than say… four CSS files, four javascript files… since that would be six less requests. If you mean dumping EVERYTHING into a single HTML file… BAD IDEA.
It’s why having a page that calls twenty separate script files can take anywhere from 4 to 40 extra seconds depending on the ping-time to the server… really though that’s an extreme example.
BUT – keeping certain things separate from your html file – like CSS and Scripts, means that sub-pages will load faster becuase those are cached. If you use the same CSS on thirty different pages, and a user visits all those pages, the single separate CSS file gets called only once… if you put it all in the html, they’d have to redownload all of it on every sub-page.
To that end making your first page load take a wee bit longer CAN be advantageous; a great example is a forums where the average visitor hits at least five pages. If you had 10k of markup per page average and 40k of CSS covering all the different things per page, they visit five pages that 250k as ‘single html files’ but only 90k if you put the CSS external and it’s cached. Not only that, those sub-pages will load and render faster because the CSS for them is already there – which is why separating out CSS that’s only used on sub-pages can often cost you bandwidth instead of saving it; and make the page seem to load slower. If you pre-cache it in a single CSS file on the first page they visit, it’ll be picked up by all the other pages they visit on your site.
Notice also I say “per media target” – Screen is just ONE thing you should target with CSS, and putting say… your PRINT or HANDHELD, or your media queries for modern mobiles inline in the markup would be a waste of bandwidth for the people who don’t use them!
There’s a reason I go media=“screen,projection,tv” on my LINK to the screen stylesheet.
Really the biggest place you can save on handshakes apart from the “dont’ call dozens of separate script files” is on icons and other small images on a page, and any presentational images you use. If you can combine them down to a single file, that’s where real benefits occur – see the inaccurately named “CSS Sprites” for where that comes into play.
Even just simple sliding-doors menu states:

Using one image to do what more conventional methods would take six separate files.
It’s why before we started doing CSS3 stuff for rounded corners and other corner/shadow effects I came up with Eight Corners under one roof – where most systems would use eight or nine images, I use just one.
Bottom line – as everyone else here has said, dumping it all into every HTML file is just wasting bandwidth; user agents can handle up to 8 requests at once, and a good rule of thumb is that anything less than 16 ‘requests’ total for a page template (not counting content images/objects) is entirely acceptable thanks to that overlap of requests. It’s only really a concern when you’re talking completely noodle doodle numbers of files like 30 or more.
Like anything else, it’s a balancing act – in this case cache vs. requests. It’s also a hefty part of why practicing separation of presentation (css) from content (html) reaps real benefits – the more ‘like’ appearance you can move into the CSS file, the smaller all your HTML files are and the less bandwidth you use; and the faster all your sub-pages will appear to the user after their first visit.
Reminds me a bit of the whole “embed small images in the CSS” thing – sounded like a good idea, one less request and all, but by the time you uuencoded the images to put them in the CSS, their increase in size would offset any gains you’d have from losing the handshake unless you’re talking >500ms ping time… which happens, but why would you penalize the people with fast connections?