The work on [2] is fascinating to me, both because of the problem domain and as a case study on the effective application of ASP. I will be reading this paper carefully to pore over the details.
I second the recommendation to start with Lifschitz and move on to the Potassco book from there. To add: One does not need to know Prolog to get into ASP, the semantics are unique and more minimal. That said, I personally struggled with ASP before it clicked, it takes time to grasp the lingo and grok the semantics if you have never worked with something similar. Best to have a guide that introduces the concepts one at a time ("What do you mean, there's more than one type of negation?!")
Potassco is a wonderful collection of software. I have used clingo recently to prototype some puzzle ideas that I had. After encoding the rules in ASP I could quickly produce a single model through clingo to see if the puzzle design was feasible or not. (I also decided to use clingo to enumerate the solution space, but it turned out to be much bigger than I anticipated and after ten days I terminated the process with just shy of a billion solutions found...)
Since then I have been dreaming of using it to actually power puzzle software, where a single logic program could be used for both puzzle generation and validation. But that's not even the only "power couple" I can think of with respect to clingo/ASP integration. There are a number of hard problems that benefit from the declarative approach and could leverage the power and speed of a solver like clingo. And with libclingo this is now a feasible option to transform your problem into an ASP program, call clingo, then transform the answer set into your solution.
ASP has both classical negation and negation-as-failure, but that is not quite why I'd say it is "more declarative". Prolog is capable of performing "imperative" tasks (by this I really mean side effects), while ASP solvers exclusively find stable models (answer sets) that may (or may not) exist for a given logic program. In ASP you can only declare a model with your input, and the output is either one or more stable model(s), or the knowledge that the model was unsatisfiable.
You are right about it being more than just a "modeling language to solve combinatorial problems", I agree that description sells it a bit short. As you pointed out, it is well suited for problems involving non-monotonic reasoning and uncertainty. You can encode reasoning that is more reality-hardened, with logical rules to deal with imperfect information.