A bunch of the technical books, especially the textbook-ish and "handbook of X" ones, aren't books you "read" so much as "read the beginning of, then skim and refer to the rest". A common pattern is that there's general material in the first 10-50% of the book, which you probably want to read, then the latter parts of the book are series of specialized chapters and sub-sections on various techniques and variants of techniques. You wouldn't normally read every page of all of those in sequence, unless you were working really deeply in that exact area.
You can also often skip loads of stuff if you're reading for applications-focused reasons rather than looking to directly extend the techniques in question as part of theoretical research. I read a lot of logic papers, because I build tools on top of logic-programming systems, and I find that out of an 8-page paper, there's usually only 1-2 pages of material relevant to me. There'll be 1-2 pages of introducing a new construct, motivating why the construct is useful, sketching how it would be implemented and how it relates to other ideas; and then 6-7 pages of proofs showing that their extensions have all the soundness and whatever properties you want them to have. When I'm reading, I read those 6-7 pages as a single sentence in my head---"and now we prove that it works"---making for a nice 75%+ compression ratio.
If you think you may be missing out on something, then you read that proof. Reading all of the proofs is usually a waste of time. (Not always a waste, sometimes they are all relevant, but usually.)
Usually no. :) The proofs are often pretty mechanical and proceed the way similar proofs do, if you've already read a few in that area (PLs proofs are even worse, a totally mechanical exercise in pages of structural induction). I actually wish there were more areas where they were just saved for tech reports and appendices instead of breaking up the flow of the main paper. When papers are 75%+ proofs, the nice nuggets are parceled out so slowly that it's pretty frustrating.
I do often read English sketches of why something works, if a paper includes them--- text that points to the core insight of why we're able to do something, which theorems or constructions allow it, which problems you might think would exist are actually avoided, etc. But I rarely need to see all the detailed symbol-pushing.
You can also often skip loads of stuff if you're reading for applications-focused reasons rather than looking to directly extend the techniques in question as part of theoretical research. I read a lot of logic papers, because I build tools on top of logic-programming systems, and I find that out of an 8-page paper, there's usually only 1-2 pages of material relevant to me. There'll be 1-2 pages of introducing a new construct, motivating why the construct is useful, sketching how it would be implemented and how it relates to other ideas; and then 6-7 pages of proofs showing that their extensions have all the soundness and whatever properties you want them to have. When I'm reading, I read those 6-7 pages as a single sentence in my head---"and now we prove that it works"---making for a nice 75%+ compression ratio.