It's not Ruby-specific jargon; it's common to most all debugging.
Regarding stack frames
You've likely seen stack traces:
/usr/local/rvm/gems/ree-1.8.7-2010.02/gems/redgreen-1.2.2/lib/redgreen.rb:28:in `write': Broken pipe (Errno::EPIPE)
from /usr/local/rvm/gems/ree-1.8.7-2010.02/gems/redgreen-1.2.2/lib/redgreen.rb:28:in `output_single'
from /usr/local/rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/test/unit/ui/console/testrunner.rb:72:in `add_fault'
from /usr/local/rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/test/unit/ui/console/testrunner.rb:70:in `to_proc'
from /usr/local/rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/test/unit/util/observable.rb:78:in `call'
The full trace shows you the "call stack". The line at the top is where the exception was thrown, and the lines under it show the path through your code that the program took to get to that point. Each of those lines is a level in the stack, called a "stack frame". So, when an exception is thrown, the current stack frame is the top of the stack. If you move to frame -1 then you're moving to the bottom of the call stack. Think of the call stack like a stack of plates. When you call a function, you add a plate to the stack, and when you return out of that function, you remove a plate from the stack. Each plate is a frame. Since you usually end up calling functions within functions within functions, you end up with fairly deep call stacks, and walking up and down them can be useful in debugging, to evaluate local variables and state at each point in the call stack.
If you'd like to read up more on call stacks, Wikipedia has a nice article.
Regarding threads
Most all modern programming languages are multi-threaded, meaning that they can execute multiple code paths (almost) concurrently. So, imagine for example that you have a visual app, and you perform some expensive computation. Your GUI won't be able to react to any user input while that computation is running, which makes the application appear to be frozen to the user. You would solve this by running two threads: One thread would be responsible for accepting and handling user input and painting the GUI, and the other thread would be responsible for doing your heavy computation. Your compute thread could be stuck in an expensive loop and your GUI thread would keep running and painting the GUI.
If you are running a multi-threaded application, then you you have to select which thread you want to evaluate your debug commands (expressions) in, since each thread will be in different points of your code, and will have different call stacks and different local variables and state and such. This is the evaluation context.
However, I noticed that this is a Rails question, and Rails is (by default) single-threaded, so you shouldn't need to worry about threads.