Forget 2^63, and forget nested loops. Think instead a loop with maybe 2000 iterations --- that seems like the frontier of what the verifier will let you do right now. The verifier's budget is 1MM cycles, for the whole program, including each tick of every loop in it. That is to say that the verifier is literally going to execute your program symbolically, and give up after that many cycles, or at any loop where it can't easily see that the induction variable is bounded by a program constant.
The idea here is that without any kind of loop, it's quite tricky to do some basic packet processing. For instance, if you want to clamp the MSS of a TCP connection, you have to grovel through TCP options, which do not occur at fixed offsets or in a particular order; you want to write a "for" loop over the (inherently limited) range of bytes at the computed offset of the TCP options. You can trivially bound that loop by the MTU of the link your program is loaded on (and also the limited possible size of TCP options), the loop won't iterate that many times, and it won't do much inside the loop.
But it's very much not the case that bounded loops give you general-purpose programming, like to implement your own data structures. BPF programs rely on kernel helpers and userland programs that maintain maps and read perf to do that stuff.