I apologize I can't go into more detail about this functionality, but I would like to make a couple notes about the Linux-ARM port. First off, for reasons of technical feasibility this release represents a snapshot, so any function that you find and *especially* functions that did not exist before could have their performance and behavior change drastically within the next year. So, for that reason alone some of what you find might not be fully representative of language features we release in the future. That said, the character of performance on the Raspberry Pi is significantly different also because it simply doesn't have the same level of machine optimizations we have in our x86 builds. Those optimizations are coming over time, but I would caution you against judging the character of performance on functionality on this platform in general for this reason.

As a hypothetical example, a developer writing new functionality might rely heavily on functions that have high performance CPU-specific optimizations applied in the case of our current development build. While this would be a good practice for building future-facing functionality for the product, the Raspberry Pi port might not have such optimizations available and instead rely on an implementation of a given function that performs orders of magnitude slower than on our optimized build, even with the difference in performance between a modern x86 and ARM11 processor taken into account. So, in this hypothetical example, functions that predate those optimizations might outperform the newer code because they may not have been written with that optimization in mind. I can't speak in detail about this given functionality, but for reasons like this I think it would be very easy to mischaracterize the performance of langauge features judging by the Raspberry Pi build alone. I strongly recommend waiting for the next official release of the product to scrutinize the behaviors and *especially* performance of new functionality. 

I don't have a Pi to play with, but offhandedly, Associations allow the most straightforward OO-like behavior in terms of syntax. It's possible the people at WR had this in mind, given the sugar for string keys:
If there was a way to give Associations default values (like the third argument to Lookup, but automatic), you could even have a basic form of inheritence (so-called prototypal inheritence, sans 'this'/'self'). Hopefully no one listens to me though, because the thought of OO-y Mathematica, even of an immutable flavor, brings great disgust to my loins. Although, because Associations are immutable, you can actually accomodate for inheritence just by adding onto the parent. Whoaaah. [1] This might end up being a lot more useful than it seems at first glance.

But even just in terms of basic functionality, I do have a couple programs where Associations would straightforwardize things. It's definitely a "quality of life" improvement, since otherwise you have to choose between intentfulness of declaration (Rules) vs ease of use (Functions).

[1]