BURP is for bulk rendering. We have a massive startup overhead for each session (read: sometimes days!) but make up for that in compute capability. At some point another BURP-based site actually had a rule saying that sessions had to use at least X minutes of rendering time in order to be accepted.

There is no set rule or limit - only a soft limit to how long we will run a single part (of a frame) which is around an expected 8 hours and an actual hard cut-off time of a couple of days of time on a modern multi-core machine. Currently two sessions are running which may hit that cut-off because they couldn't be split into parts. Generally we try to keep parts within the 1-4 hour ballpark area if at all possible.

Apart from that (no pun intended, of course) the sky is your limit. If you can manage to use the frame-splitting feature and your target resolution is high enough then you could potentially hit many CPU years of compute time per frame.

The hardest session we have rendered, so far, was around 108 CPU days per frame and had 175 frames. The longest session was 92783 frames. The highest frame split was 300 parts/frame. The largest frame was 17280x17280.
We are limited to at most 2147483647 frames per session and 99999 parts per frame but there are some rules for how to use parts that rely on the resolution of the session. Also, presently no more than 256MB of zipped result data per frame (that limit is mostly relevant to multilayer HDR EXR rendering).
Someone tried to render a 55118 pixels image once, but Blender kept crashing on it, so we don't currently know the exact limit on the resolution that we support.

Of course it is also a balance and sessions are validated by a human being using common sense before being accepted. If someone puts in 999999999999 in the sample target field on a Cycles session for no other apparent reason than to burn CPU hours then that session will very quickly disappear from the session queue.