There are two different topics here, really: in-application scripting and application development proper.
Creating Applications Without C++
The benefit is that people can write applications faster and with fewer errors, not to mention they don't have to learn C++ if their language of choice and expertise is Python or Ruby. That means that we could see more applications with fewer defects coming from a larger audience.
In 2009, we saw the first non-C++ application ship with the KDE Software Compilation: a printer configuration tool. There are many other great Python/Ruby KDE applications "out there" coming from the wider audience of people who write software with the KDE Development Platform. It would be great if in 2010 we can raise awareness of this and as a result grow our third party development audience as well as see increases in efficiency amongst some of our own application projects.
Now, there is some downside to divergence from C++ as a "lingua franca": it is harder for someone who doesn't know Python to contribute to a Python application. However, based on my experience in doing so, it's completely within reason. (I don't "know Python", per se, but I have contributed patches to Python applications despite that. :) This is in large part offset by the fact that we don't rely on the language itself as much as we rely on the great APIs that Qt and KDE deliver as our "lingua franca". Which is to say: a KFileDialog in any language is still a KFileDialog. ;)
While having a multiplicity of languages and not caring particularly for the overhead of them is completely acceptable, and even comes with some benefits, in the application development arena, the landscape is a bit different when it comes to application automation, aka "scripting".
Such scripting encompasses a wide range of applications: from writing bits of glue in a spreadsheet to writing extensions for Amarok to Plasma widgets, in-application scripting can transform an application into a static black-box experience into one that can be easily extended at runtime by even novice users (by using scripts from other less-than-novice users) while still keeping the default user interface sane.
The choice of language here is probably a bit more critical than with application development. The choice should appeal to the widest possible audience, should be available (e.g. installed) on the widest number of systems and should (paradoxically) not include so much more functionality than actually needed that it becomes a management nightmare for the user. That last point is one that is usually learned by application developers the hard way by offering support for, e.g. Python scripting, only to find that some of the scripts written and being shared around require some obscure or version-incompatible bindings/additions/API extensions to the language making it much trickier for users of the application to reliably use scripts from a shared repository.
This strategy, which can be seen being employed to great results in other hugely successful pieces of software such as Microsoft Office and Mozilla Firefox, can help us create more streamlined default interfaces with more options for our users in a manageable fashion. Combined with the increased traction we're seeing right now, this could be one of the signature shapers of KDE software in 2010.
We have excellent tools (QtScript as well as Kross) that make it really quite easy to accomplish it in our applications. What are we waiting for? :)
(This article is part of the "Key Quests for KDE in 2010" series)