All abstractions are leaky to some degree. There will be problems you don't understand if you don't know what's happening one layer down. This is not to say there's something wrong with being a tinkerer - but it is saying that there is a difference between a tinkerer and a professional. http://www.joelonsoftware.com/articles/LeakyAbstractions.htm... for better writing on this topic.
Well you don't need to know opcodes, but that's an implementation detail. If you don't have at least a basic understanding of what the machine is doing, you will never be able to really understand the code you write.
Let's take someone who has learned Ruby outside of the classroom and is now attempting a relatively simple Ruby on Rails site. What disadvantages does he/she have not having studied assembly (as most com sci/engineers do at some point in their coursework)? Are these disadvantages major compared to, say, the disadvantages of not having learned HTML and attempting to be a RoR dev?
I would guess no. But I've learned both assembly and HTML so I can't tell for myself how much either has influenced me in ways that I'm not conscious of. Except that I actually use HTML knowledge when designing RoR views.
Ruby presents a VM; someone who understands the capabilities and limitations of that machine will be able to write Ruby code much more effectively than someone who does not, simply because they will understand what they are writing.
It would not shock me if most Rails devs were in fact Ruby tinkerers; and there's nothing wrong with that, if that's all you need to do.
Every time I've heard people discuss that level of concern over code speed or space considerations the topic turns to C extensions. I cannot recall ever hearing or reading about tuning ruby code for its VM. Or even C code. Perhaps that's because I've never had the need to be concerned about it, but if there exists any writings or conference video on this i'd be curious to take a look.
That's just an absurdly untrue statement.