I find web interfaces a perfect fit for erlang, with lightweight http servers you can add to your application at little cost, startup a web server with your application and you can code the gui in xhtml / css / javascript, you get can use the app remotely for free :)
quite a few of the erlang standard tools can be ran this way
Web interfaces are not bad for Erlang, although my intuition says the real sweet spot would be in doing the GUI in Javascript and simply passing JSON back and forth. HTML templates with Erlang are unpleasant compared to something like Ruby or Tcl, which were made to be very DSL'y and good at mangling text. So if you can skip the text wrangling and HTML templates and simply offload that to Javascript, that makes Erlang more competitive.
erlang now has a run queue per core as opposed to a single run queue, which will improve things, and they have also improved message passing characteristics and ets table locking optimisations.
the "problems" with >16 (and even >2) cores have not particularly been with the erlang runtime, quite often its an inherent problem with the application or at least the way its been written
