Using a factor or forth, Arc or whatever as an example (note: factor is a bad example because it has a large set of practical libraries). Lets say you are considering using a programming language. Does having a large set of practical libraries matter? If your language is well designed, then it would be easy to create a 'string' library or a 'date' library. Maybe even a web framework?
I mention this, because when a language emerges, it seems that someone brings up 'practical libraries'.
Practical libraries are important. I don't get paid to write a framework, I get paid to add value to a business. If I told a client I had to charge them to write a string data type, I'd probally lose my job / contract.
It definitely matters - nine times out of ten, I'm going to pick a language with good, well-supported libraries that help accomplish what I want to do.
This isn't to say I wouldn't enjoy writing my own libraries (quite the contrary), but for a production project where quick, accurate results are important, that wouldn't be a practical option by any stretch of the imagination.
Just look at the majority of questions here on SO to see how important tools are to people.
That said, if you find a new language that fits your task really well and you have the time and inclination to write your own tools then by all means dive in. That's one way that new languages get nice libraries, after all.
Java and .Net have spoiled people with the abundance of classes in the framework or in additional high-quality libraries (quite often free and open source as well). Same goes for Ruby and Python. It'd be hard to adopt a new language without such a library, as your productivity will suffer teremndously by having to reimplement every single feature you need.
Unless it's a breakthrough language that introduces something radical like intentional programming (I tell the computer what I want it to do and it inferes the proper code to do it)... Why, you have one of those? :-)
A large library makes a language much more productive to use. A really great language without support for parsing XML, crypto, a web framework, a UI framework, etc. takes a lot more time to produce working code with. For learning purposes, a language without a large library is fine, but for practical purposes, it is going to cost time and money to use such a language. Imagine if every time you wanted to load an image you had to write code to parse the .jpg headers. What if you had to hand-code your XML parser rather than loading it into a pre-built one. You'd likely screw it up and spend a lot of time debugging. If the goal of the project is to create a new tool, writing support code is not a great use of your time.
I think that the big reason for Python's popularity is its huge standard library. Same goes with Java and PHP. In fact, I'd probably say that the selection of libraries is more important than the language itself.
If your top priority is to create a finished product with the least amount of time and effort possible, then yes, having available libraries matters. (If your goal is fun, or learning for the sake of learning, then writing your own libraries can be a good experience.)
A good library is mature enough that lots of people have used it and weeded out most of the bugs. It doesn't matter how great your programming language is or how easy it is to write a library from scratch. There's no replacement for having your code tested over time.
A lot of libraries are not interesting or fun to write, and reimplementing them again is not going to revolutionize the world in any way. There is only so much you can do with a date library or a string library whatever. It either works or it doesn't. Many libraries are simply an implementation of a standard or of some de facto standard behavior, and someone just has to slog through the necessary work to get it right. The less of this you have to do yourself, the better.
Any brand new language that can take advantage of existing libraries starts off way ahead, in my opinion. Clojure for example, though a very new language, also has access to all the libraries of Java. This is arguably one big reason it's doing so well at the moment. Effort is put toward novel things rather than re-inventing wheels.
It's a tempting idea, and it certainly works if you're Paul Graham or Chuck Moore.
It might work if your domain is very very bounded, and you're not going to get a requirement thrown at you that's outside that domain, something as simple as a client asking for an "import from Excel" feature. On the other hand, Paul Graham used Lisp to write a web shop system, which is a very broad domain of requirements; I'd be interested in knowing how he handled something like a PDF export, would he have given the PDF spec and a Lisp manual to some intern on summer vacation from MIT, or would he have gone down to the C libraries?
It might work if your domain is driven by logic or by enduring natural principles, something like an astronomy simulation. If they're human requirements, they'll be full of contradictions and special cases (string and date libraries fall into that category, by the way), and there is no abstraction or language feature that entirely cuts through that, you'll have to slog through the special cases whether you're writing in Haskell or PHP.
It might work where optimisation is very very important (EDIT: and where you're smart enough to optimise it yourself) - you have a stripped down system where you know every layer of the stack because you've implemented it yourself with a particular goal in mind.
I associate the whole cluster of ideas with grad students: they're in the top 1% in programming skills and general smartness; they're working in a very narrow domain; they may not have the best equipment so they're trying to strip things down and optimise in depth; and they don't have the learning vs getting work done dilemma of working programmers.
You think string libraries are easy to write? Go have a look at Unicode, UTF-8, UTF-16, legacy codepages, byte order issues and whatnot.
You think date/time libraries are easy to write? Go have a look at leap seconds, week numbering schemes and whatnot.
Having these kinds of things thought out for you, implemented once and implemented properly, saves more time and headaches than you think.