One question, I couldn't answer:

Should we use more or less nodes?
Should there be the least amount of cycles?
Should we have many or few instructions?

I think:
Cycles: the less the better
Nodes: the more the better (distributed computing to decrease the cycles needed)
Instructions: the less the better

You could also say, use the least amount of nodes and instructions to do the job in a resonable amount of cycles?

p.s. and there is also aesthetic of the code, do I squeeze as many instructions as possible into one register or try to distribute them in an organised way (which makes the code slower, but more resonable).

There are 3 save slots, so it's entirely up to you... I sorta think of it this way.

Node 1: Just get it done!
Node 2: Go for fastest
Node 3: up to you...

Using more nodes and instructions could be more power that's used when you think about it. But that's unlikely. Speed and instruction size is more important, sides the later ones you might need most of the nodes just to solve the problem, optimizing becomes more and more a pain.

The index one for example, not enough room to manage handling traversing the array for optimization, so i had to just have it cycle one way, and reset another. It was slow, tedious, but worked. It also used the fewest nodes, but the cycles being lowest is where i'd put my money :P

Also heavily for optimization, you will start relying on JRO jumps A LOT. Think of them as a function caller and your functions being 1-2 instructions plus a resetting jump.

I would say "all of the above". My first solution to each puzzle is to try to do it with as few nodes as possible. I basically go directly from the input(s) straight to the output using the shortest path and no unnecessary nodes by default. This means that my first solution usually gives me the best "low node count" score, but not always the lowest cycle count or instructions.

After I've solved it I name it "##ORIG SOLUTION" then copy it to the 2nd program slot and try to optimize it using a variety of tactics such as changing the loops to optimize for the common path sometimes via statistical analysis of the data inputs for example, as well as by experimenting with different ways to do the same thing. I try to factor out duplicate code wherever possible and other tricks similar to what you would do in real world assembler programming when you're trying to reduce cycle count.

If I think the problem in question might be able to be solved by acting upon the data in parallel, I may utilize as many other spare nodes as the parallelization seems to benefit from, however sometimes there is an upper limit upon which adding more nodes adds more processing overhead that can slow it down rather than speed it up. I've shaved significant numbers of cycles off my execution time on a number of the puzzles by using parallelization. Sometimes you have to reorder the instructions within a node as it farms out data to other nodes in order to optimize it for parallelization. It's actually quite fun experimenting to see what works best.