To the performance aspect, a modern Just In Time compiler will In-Line the setter call if it is truly just a trivial set. There's no allocation of a new method stack or any of that cost to consider. Avoiding using getters/setters isn't really a performance concern even as a micro-optimization. (yes there is a cost to perform the inline, but the question refers to webapps, where ostensibly that happens once and the server remains up indefinitely.)
So some things in favor of using the setters
1) The setter may not be just a simple set for all time. I guess this is some personal opinion, but hoping automated tests will catch any and all bugs possibly introduced by skipping a setter that later gains side effects seems naive.
2) Set methods may be instrumented at run time by other frameworks. Persistence systems and aspect oriented programming frameworks can both add additional functionality to set methods that isn't seen in the source of the class. And again, just because one isn't in use now, doesn't mean it never will be.
3) A field that is accessed via a set method is clearly externally visible and changable state, as opposed to a truly private field with no accessors that is clearly internal state. It can improve understanding if the fields that represent only internally managed state "stand out" in code for lacking set calls.
4) Fewer worries about bugs where people leave off the 'this.' and set a method scope variable instead of the instance scope variable that they hid sloppily. (It's amazing how many people have conditioned themselves to completely ignore compiler warnings, even in IDEs that highlight them.)
In favor of not using the setter
1) All I can come up with is some people may find it easier to read.