I assume you're talking about read-only properties, or at least property getters, since a property setter is, in almost every instance, going to have side-effects. Otherwise it's not very useful.
In general, a good design follows the principle of least surprise. Don't do things that callers aren't expecting you to do, especially if those things might change future outcomes.
In general, that means that property getters should not have side effects.
However, let's be careful about what we mean by "side effect".
A side effect is, technically, any modification of state. That might be publicly-accessible state, or... it might be totally private state.
Lazy/deferred loaders are one example of state that is almost exclusively private. As long as it's not the caller's responsibility to free that resource, then you are actually reducing the surprise and the complexity in general by using deferred initialization. A caller does not normally expect to have to explicitly signal the initialization of an internal structure. So, lazy initialization does not violate the above principle.
Another example is a synchronized property. In order for a method to be thread-safe, it will often have to be protected by critical section or mutex. Entering a critical section or acquiring a mutex is a side effect; you are modifying state, usually global state. However, this side effect is necessary in order to prevent a much worse kind of surprise - the surprise of data being modified (or worse, partially modified) by another thread.
So I would loosen the restriction a bit to the following: Property reads should not have visible side effects or side effects which change their semantics.
If there is no possible way for a caller to ever be affected by, or even aware of a side effect, then that side effect is not doing any harm. If it would be impossible for you to write a test to verify the existence of a particular side-effect, then it's localized enough to label as a private implementation detail, and thus of no legitimate concern to the outside world.
But do be careful; as a rule of thumb, you should try to avoid side effects, because often what you may think to be a private implementation detail can unexpectedly leak and become public.