This had me scratching my head for a while...  however I think I know where the problem lies and why the effect isn't consistent.  When you add balls, that have previously been removed, back to the balls ArrayList you pick them at random; however the id property of the ball object is based on its position in the ArrayList at setup.  By adding the balls back at random you're changing the order of the balls in the ArrayList so that the id no longer represents the position in the list.  That id is important because it's used in the collision detection to avoid duplicating collision checks:

1. void collide() {
2.  for (int i = id + 1; i < others.size(); i++) {
3.   //etc...

This approach to optimisation works in the bouncing bubbles example since their order never changes, but in your case I don't think it's going to be suitable.  You're better off taking the more usual approach of checking for collision detection outside of the object using a nested for loop.  There's plenty of example of this in the forums ;)

A couple of other points.

1.  Setting the speed:  That's set by vx and vy.  You could set these to small positive/negative random values in the Ball constructor to always get movement.  The reason they sometimes fly off is probably when they land up being positioned on top of each other at setup: it's caused by the collision detection kicking in.

2.  This method is superfluous:

1.   void update(){
2.     others = balls;
3.   }

others is already set as a reference to the balls ArrayList in the Ball constructor.  When balls changes, others changes with it...  i.e. there's no need to manually copy* it when it changes.

* in actual fact you're not copying it at all - you're setting a reference to it.  This is a common mistake people make, most commonly with standard arrays.  Again this issue crops up in the forum often.