Is speed of the (main/only viable) implementation of an interpreted programming language a criteria today?
What would be the optimal balance between speed and abstraction?
Should scripting languages completely ignore all thoughts about performance and just follow the concepts of rapid development, readability, etc.?
I'm asking this because I'm currently designing some experimental languages and interpreters
As fast as the developer need it to be.
There is no rules, just needs to be feed.
Speed is important, yes, but usually scripting languages are used in cases where speed of execution is outweighed by I/O costs, so it's not the end-all, be-all. Of far more importance is the language structure and features. Work on those first, then deal with execution speed.
That said, I think ultimately if you're looking to build a new general purpose language, you're going to go the route that most of them are going, which is pre-compilation into a bytecode and JIT compilation during execution.
There is no only answer to a question like this. No one answer can apply to all the possible purposes and audiences.
Probably the single biggest factor to take into account is whether you intend for the language to be mostly standalone, or used in conjunction with something else. If you write something like Lua that's intended primarily (or exclusively) for use along with something else (C in Lua's case) then speed becomes much less relevant and interesting. If you write something that's used primarily by itself, speed starts to matter a whole lot more.
You really have to answer these questions for yourself based on the goals of your experiments.
Speed is always relevant unless your language is useless. If it's useful, people are going to try to use it to do some heavy lifting, and if it doesn't fall on its face when they try, that's always better. This doesn't mean that it is worthwhile to optimize for speed (that depends on your goals), nor does it tell you how (e.g. fast compilation to bytecode vs. reworking how you access a high-level library written in C so that the interpreter has even less to do before calling it).
The optimal balance between speed and abstraction depends on the types of problems being solved. Computer time is generally less valuable than people's time, but both are worth something. Neglecting computer time entirely, it's still useful to consider how much time will be taken total by people working and waiting for results; users of the language ought to be maximally happy when the total coding + execution time is minimized. (Weight by salaries of coders vs. users if you want to make a maximally strong business case.)
Because of the previous two points, I think it's a bad idea for interpreted languages to completely ignore performance. Of course, if the language is experimental itself, you have to ask yourself how much time you want to spend working on performance instead of adding features. It can be okay for an initial implementation to be horribly slow if it will be gradually optimized as it is used more frequently and for more demanding tasks. JavaScript is an excellent example of this.
I don't understand why anyone would write an interpreter these days. There are two excellent virtual machines, the CLR (+DLR) and the JVM. It's trivial to write a compiler for either runtime, and then you get the advantage of interoperability with the massive amounts of existing code out there, plus fantastic standard libraries, plus JIT compilers that will make the speed of your language a non-issue in many cases (certainly faster than any interpreter.)
If you want to make a language that will be more than just a curiosity to developers, this is definitely the way to go these days.
I'd go for a language with a great API, personally. If you look at Lua, 90% of the Lua C code people write is just boilerplate. If a slower language, with much better C++ API came around, I'd switch to that in an instant.
Ultimately, "premature optimization is the root of all evil", and that is, your language needs some great features, AND it needs to be fast. It's no good being fast if it's as usable as assembler, with the user having to implement the operating system.