Since you usually work across an org chart (not _in_ an org chart), and the company is paying more for your time than their FTEs, you can make great impact in relatively little time. Consulting is also great if you have trouble staying at a single place, as you usually don't spend more than a few months at any given assignment. (Usually. I know consultants who are on multi-year assignments with a single client. Those projects are usually very large.)
The disadvantage of being a consultant to large companies is that you're usually not working at the cutting edge, though this depends on the context for your presence. You're more likely to go deep (i.e. tweaking kernels, re-compiling source for major OSS products, etc.) if you're with $CLOUD_PROVIDER working with a client spending millions/year with them than if you're with a boutique consulting shop doing high-level strategy for which technical implementation is a minor factor. This is usually patched by your consulting company's bench time policy.
A consulting company is only as good as the consultants they employ. Good consulting companies hire opportunistically (i.e. ahead of their sales pipeline) and budget large bench times. In other words, their profit models plan for their consultants to spend, say, 30% of the year unassigned so that they can train/work on personal projects/breathe/etc.
Not-so-good consulting companies (IMO) (or very sales-driven consulting companies) hire just-in-time and expect their consultants to be staffed more than 85% of the year, with any training done after-hours or during the weekend. These outfits typically operate closer to agencies or contingent labor shops where profit is directly proportional to the number of people they staff, but some newer consulting companies start off like this (because it's easier) but never aim for the former model (because it's more expensive).