You've got two options for integrating C code in any Ruby application: RubyInline and Ruby C extensions.

RubyInline is incredibly powerful. You can drop C straight in to your Ruby scripts for operations that would be too computationally intensive for Ruby.

Ruby C extensions are more powerful, as they allow you to call C code from within Ruby. However, it does require some alteration to the C code, so this won't do if you have a closed source C library.

As others have suggested, there are ways to make system calls from within Ruby, and with the way things work on Unix systems, that's a perfectly acceptable alternative.

Also, to address your question more generally, there's nothing that says you must constrain all your code to the confines of MVC logic. Gems are packages of Ruby code. If you find that you need a set of objects to handle complex business requirements, you could always package up that code as a Gem for use and distribution within your company. Gems are very easy to build and include in your projects, so the barrier of entry is very low.

I've been working with Rails since version 0.7. I've seen a lot of developers convince themselves that their problem doesn't fit in to the Rails box. While I always advocate using the right tool for the job, most people are wrong when they reach the belief that what they're doing isn't a good fit for Rails. It's usually an inability to understand where their ideas fit in to the broad scope of the MVC design pattern.

Having said that, there are plenty of ideas that don't fit Ruby on Rails, or MVC for that matter. Twitter was a great example. You don't implement a ultra-high-volume, low-package-size messaging system using an off-the-shelf MVC framework.

Very few problems are Twitter, however. Most business problems are 90% CRUD with a sprinkles of interesting work in between. Rails is a great fit for these types of projects because the "magic" peels away gracefully when you need it to.

There is another aspect of Rails that doesn't get much lip service. Rails is great because it makes a lot of decisions for you. The developers call this being "opinionated software". Maybe I'm just a little too humble, but a lot of the guys that work on Rails are bigger thinkers than I am when it comes to software frameworks. A lot of people won't admit it, but there is plenty of software that tries to copy the Rails way of doing things. That's at least some level of acknowledgement that they're things right. What I'm getting at is that there is a lot to learn from digging in to Rails on a deeper level.

The "Rails way" also extends beyond actual development and in to deployment strategies. Before we moved to Rails, we didn't have a sound deployment strategy. Rails developers just assume that you're going to use some type of SCM and deployment strategy. The most common being Rails/Git/Capistrano. If you say on the beaten path, there is a tremendous wealth of information available for all manner of deployment strategies. Again, these solutions fork for 99% of use cases. If you're a one-percenter, you're not going to benefit much from Rails, but make sure you've qualified your case and not just suffering from a case of "I'm smarter than the world."

That wraps up my thoughts on the matter. I'm sure there are other perspectives out there.