General
zsync makes an unusual pattern of requests; because it is retrieving lots of small parts of the target file, it will typically result in more than one hit appearing in the server's log. It could also put slightly more load on the server than a simple download (although it should be much faster and use less bandwidth).
Of course, if the server operator themselves has created the .zsync file, or has given permission for it, then there is no issue. And in any case, zsync saves bandwidth and doesn't do anything except do selective downloads of bits of files, so it should not cause a problem. Its traffic is not much different to, say, Adobe's PDF viewer that also does partial downloads.
zsync has been programmed conservatively so that it is unlikely to annoy a webmaster. It even self-imposes a few restrictions to prevent some less-than-ideal traffic patterns that could spook the webmaster. I would just ask that people using zsync exercise the same care in using it.
Server Partial Content Support
To make use of zsync, there has to be a server holding a full version of the content that supports partial downloading (Range requests). And, reasonably speaking, zsync needs slightly more: support for multiple byte ranges per request; without this, zsync has to make a large number of requests to do any sync where there are a large number of scattered changes.
Redirects
zsync follows redirects on the .zsync file, and sets suitable referer headers.
zsync 0.6 and earlier versions refused to follow redirects on the target file, because, due to the number of requests it makes, it is impractical to revisit the original URL to get another temporary redirect before every request. You need to regenerate the .zsync if the URL of the target changes.
zsync 0.6.1 and later do follow redirects on the target file. Note that you can't use temporary redirects to load-balance single sessions of zsync — it treats all redirects as permanent for the duration of the session. It is simply not practical to maintain a pipelined connection to maximise throughput if the individual requests go to different servers (at the request of the server; the client could do it if it was programmed to do so, although it currently does not). zsync won't remember redirects between runs so you can use 302 redirects to load-balance if you have multiple clients (which would be the normal case for zsync's intended use, file distribution).
Note that you are still recommended to put the correct, direct URL in the .zsync file in most cases; only where you need the redirect for load-balancing is it desirable to put in a URL that is a redirect. But the redirect support is also useful in that it allows servers to be restructured and redirects put in place and existing .zsync files will continue working.
