First, do you like Arc? Do you read the tutorial (http://ycombinator.com/arc/tut.txt) and say, "Oh, yes, this a language I want to program in"?
Second, are you in a "known problem, known solution", "known problem, unknown solution", or a "unknown problem, unknown solution" situation? Do you know yet exactly what it means for you for data to be "organic" or "dynamic"? Arc is an excellent language for prototyping, sketching out ideas, trying things out. In a day you could make a small web application that stores and retrieves data, and you could try one one "dynamic" or "reflective" thing and see what you thought of it when you tried it out for real.
Third, are you offering SaaS, software-as-a-service, as for example how Salesforce does? That is, are you storing your customer's data for them? Now you can use whatever server language you want, your customers won't know or care. If Arc gives you a competitive advantage because of its flexibility, you can go ahead and use Arc.
And, by the way, I wouldn't start off using MySQL to store data. Just keep it all in memory backed by files on disk. SQL databases are good at quickly looking up records on computers that don't have very much memory, but they aren't particularly "dynamic" or "organic".
Fourth, are you asking client businesses to work with your code? That is, as you say, do you need other businesses to "commit resources to learning it, making use of it, and deploying or employing it's use"? If so, then no, I would not use Arc. Other languages impose restrictions so that bureaucracies can use them. The trade-off is that then the languages they can use are less powerful and so their programmers are less productive. But you can't go to a bureaucratic business as say, "hey, you should use Arc, it's more powerful", because you won't be meeting their bureaucratic needs.
