I doubt that a 6502 / derivative has the ability to handle it purely from a performance point of view. You lose a hell of a lot of that hard-procedural programmed performance with OO as your working with something that is over-abstracted.
I've already pointed out earlier that the 6502 family is, thus far, not at all optimized for OO. That is a given, and really isn't contested. Nonetheless, with domain-specific optimizations, you can make the 6502 competitive with the 80386 in dispatch speeds, which is good enough in most cases.
Claiming that OO is a poor abstraction model will require a TON of proof to back up -- if you examine the tenets of modular programming, you'll see that OO is pretty much exactly modular programming, but on a finer scale, and is often enforced by the language (finally). The reason everyone is all googley-eyed over OO on more powerful processors is precisely because, for the first time since they got out of college, they're actually following the advice of Wirth, Djikstra, and Knuth, even if they don't realize it, and finally starting to reap the benefits.
OO does introduce one feature which modular programming didn't yet have -- that of type inheritance -- and one convenience that modular programming hadn't yet invented -- dynamic dispatch (aka polymorphism). However, the Oberon programming language (Wirth) proved that these can be added to a normal, procedural programming language without going hog-wild with OO specific syntax. Indeed, Oberon-2 doesn't even add a single keyword to support such "type-bound procedures."
As with any software development tool, it can be abused, or it can be used properly. I natively think and write all of my software in terms of objects, but I rarely use an OO programming language, for example. Objects truely are the only way to manage open-ended runtime expandability (e.g., to provide for plugins). See COM and CORBA. Writing in terms of objects also makes it significantly easier to identify module boundaries, even if you never decide to support 3rd party expandability.
Part of the issues surrounding OO is that it hasn't made good on its promise of plug-n-play software. No, of course not. Nothing ever will. But some technologies sure make it easier. COM and CORBA for example are not 100% object oriented, despite their marketing names. They are *component* oriented, where a component is defined as an object that exposes a predetermined interface. You can create new components that inherit the interface of another, but you cannot perform implementation inheritance -- in other words, you have to hand-implement every interface yourself. Nonetheless, this has still resulted in software which is overwhelmingly more popular with the buying public, since now they can add customized tools to frameworks much easier than, say, with MFC or with Java's libraries. For the first time, people don't need to know a programming language to do this.
This leads one to conclude that having the principles of normal, procedural, modular programming as espoused by Wirth, et. al. applied to instances of individual data types, rather than to modules as a whole, is the proper course of evolution for programming, and results in the most future-proof form of programming. See the Oberon System for an example of a non-OO-language which nonetheless still provide explicit support for components, and indeed uses them *extensively* internally, yet provides a level of performance that makes Windows 2000 and Linux quake in their boots with fright. Oberon System is only about 6MB of code when compiled (including the base set of user applications), of which only those pieces which are actually used are loaded into the computer's memory (Oberon's modules, as with its predecessor Modula-2, are dynamically loaded as needed).
In light of all this, I therefore conclude that 'over-abstracted,' as you claim OO is, is an over-reaction based on relative inexperience with the true breadth of OO technology. Remember that C# is hardly the end-all, be-all of OO programming languages, and actually represents one of the worst examples as far as languages go (it's back-end execution engine is quite good, however), as it falls squarely in the Java-inspired-just-to-compete-with-Java language category, where the arguments of over-abstraction can be reasonably applied (though, I personally blame the execution of the concept rather than the language for the programming model it exposes; a good compiler would be able to statically optimize all the OO cruft, thus resulting in equivalent generated code as a procedurally written program that does the same thing). However, these arguments do not apply outright to C, C++, Ada, OCAML, Oberon and all of its derivatives, or even Object Pascal, which is still very much a procedural language at heart.
You might choose to refer me to the so-called "table oriented programming" model, which is pure procedural, where data is maintained in a table, such that a duality with objects exists: columns refer to object's fields, and rows to individual instances. (BTW, TOP is used in most closed systems, contrary to some beliefs, to help manage memory. See slab allocators, for example, which is a form of TOP). IF you can guarantee that the precise table schema will remain static throughout the entire lifetime of the running program, then yes, you can exploit this to write your code in a purely procedural manner. However, OO excels where you *don't* have a purely static schema. A graphics drawing program will often deal with outlined and filled shapes for example. A filled shape has an interior pattern, and often a set of interior colors too, while a hollow shape has zero need for these fields. A table-oriented approach would never be able to handle this situation. The problem is exacerbated when you open up the toolbox to allow 3rd party developers to code their own graphics primitives.
In conclusion, OO has its place, and I think you'll be quite shocked to realize that it applies itself quite nicely to a wide variety of applications. OO provides a set of guidelines one can use to build the ADTs and modules you'd need in a procedural language for a statically bound program. OO provides the basis for interface specification rules allowing for open-ended, 3rd party expansion after-market. And in the more powerful procedural languages like C, C++, and Oberon, you can mix/match the two applications of OO on an as-needed basis, along with pure procedural, traditionally written code to boot, thus letting you choose specifically the abstraction level you need for your application.
I blame the programmer, not the tool.
I know it's only been nine years and we have to give you time, but I'd sure like to see it if you ever get it done. 
