Only if you're performing a multistep update and want the update to be treated as an atomic operation. Here's an example:

Application.Lock ();

Application["ItemsSold"] = (int) Application["ItemsSold"] + 1;

Application["ItemsLeft"] = (int) Application["ItemsLeft"] - 1;

Application.UnLock ();

By locking application state before updating it and unlocking it afterwards, you ensure that another request being processed on another thread doesn't read application state at exactly the wrong time and see an inconsistent view of it. If I update session state, should I lock it, too? Are concurrent accesses by multiple requests executing on multiple threads a concern with session state?

Concurrent accesses aren't an issue with session state, for two reasons. One, it's unlikely that two requests from the same user will overlap. Two, if they do overlap, ASP.NET locks down session state during request processing so that two threads can't touch it at once. Session state is locked down when the HttpApplication instance that's processing the request fires an AcquireRequestState event and unlocked when it fires a ReleaseRequestState event.