Why did Litecoin choose the scrypt factors that they did? Litecoin uses the scrypt factors (N=1024, r=1, p=1) This means that each hashing thread takes 128kB of memory. The scrypt paper recommends r=8.
Colin Percival, the creator of scrypt, has said:

Q: are you into #litecoin at all?
A: I'm aware of it, and I'm aware that they used scrypt poorly (not enough RAM usage).  That's the limit of my knowledge.
Q: I'm considering enhancing #litecoin. How is scrypt being used poorly? Maybe I can help improve it
A: I'd suggest talking to @solardiz about this -- my knowledge of how litecoin misuses scrypt comes mostly from him. The 1-tweet summary is that scrypt is designed to achieve security by using lots of RAM, and litecoin doesn't use lots of RAM.

Is there a technical justification for such a low N and r?
Litecoin basically copied the parameters from a coin called tenebrix. The parameters were chosen partially because using more memory intensive parameters caused the GUI to be noticeably slow.
Listen to Charlie Lee talk about this at the Hashers United conference in Las Vegas.

https://www.youtube.com/watch?v=aHX34MbXuOk#t=469m00s
https://www.youtube.com/watch?v=qbj7aXu7FTw


[transcript starts at approximately 9:45 in the second video.]
Q: [...] But in hindsight, do you regret selecting the N, r, and p, parameters for scrypt?
A: So, the parameters I chose were copied straight from Tenebrix. The reason why they were chosen that way is because if you make the parameters harsher, more memory harsh, it actually slows down the client. Every time a block comes in, the client would actually freeze, for a minute, to verify the block, because it was so hard. At that time, it was decided, that it was a tradeoff. They decided to go with a better experience of the user using the client, and not as memory harsh, because at that time there wasn't any GPU that was capable of doing it, and it was CPU-only.
It would be great if the parameters were more memory harsh, but I think it was a tradeoff, and it was decided early on, to err on the side faster client speed instead of harsher memory requirements.