It solves the problem hackers face in every program they write, and which high level languages exist to solve: making programs smaller.
Try translating some Arc programs into Common Lisp or Scheme and you'll see what I mean.
And incidentally, I don't have to give hardened users of existing languages reason enough to switch. There are new people learning to program all the time, and to them, all languages are on a level playing field. If they look at Arc and CL and see that programs are 50% longer in CL, why would they choose CL?
Ok, I think I get it now if I look at the "Arc approach to language design" instead of "Arc in its present form". The problem isn't to come up with a better language, it's to set a good example of the better language production process and in doing so perhaps get a better language as a byproduct. Here are the morphisms I see:
a) Programs in "high level" languages can fail to be shorter than their lower-level equivalents. The simple solution: be merciless in keeping the important things short!
b) The overlooked problem in language design is high-level language brevity.
c) The "language design" problem that needs to be solved is... not sure about this one. I'm guessing it's the fact that the rate of change in the field is putting more programmers into the role of language designers at an increasing rate and anything that helps them avoid bad decisions based on ignorance is significant.
d) deliver informally as possible: when designing a new language, write enough to make the goals clear, address issues in a discussion group and put the code somewhere without sweating organizational details like setting up code repositories, bug tracking systems, regression frameworks, etc.
e) crude version 1: implement the minimal stuff using an existing system and don't worry about the fact that to the unaware it may seem just like a trivial program in that system.
f) iterate rapidly: don't get bogged down by things like release processes and backward compatibility. Just focus on getting feedback, experimenting, measuring and looking for improvements.
Arc solves the problem of making programs smaller, I agree. I'm not merely admitting that: that's exactly the thing that's impressed me about Arc 0 in the first place. But the problem with programming languages is that they aren't single-purpose honed tools: they're more like a swiss army knife, or a house that the programmer has to live in, or an operating system for the programmer's thoughts, if you will. What a programming language has in common with all of the above is that it has to solve very many problems at once: in order to be considered an unequivocal advancement, it has to solve _all sorts_ of problems at least as well as languages people are already using. Arc currently solves only one problem, albeit very well, and solutions to all of the other problems (copious libraries, that profiler thing you mentioned in one of your essays, abundant and welcoming documentation - all stuff you've identified as necessary for a successful programming language in your own essays, in fact) are being delayed until a later release, an unspecified date in the future.
Taking the analogy to a house, Arc is like a half finished construction project. The frame is up, they're still putting insulation in, and there's one finished room with a cot, a table, and a hot plate which Paul Graham is using to cook the news.yc software. Sure, you might attract scads of interior decorators by opening your house up to random strangers, but very few programmers will be willing to come over to live in Arc. They'll stay in their own houses which are already well stocked with comfortable furniture, decorations, etc., even if it is all a little cluttered and you have to go through the kitchen in order to reach the library from the bedroom.
Some of the people speaking out against Arc are genuine trolls, but some are just saying in a non-tactful way that they'd prefer to stay in a house with drywall, thank you very much.