I agree with Shvarz. There's no need to add to the language things which you can already obtain with the actual language. A few points to remember you WHY the actual language works the way it works:
1) the activation condition/ body model resembles vaguely that of dna. It is believed that the genome works as a giant network of reciprocally influencing genes; many alife simulations use neural or similar networks as a dna; the DB language is not much different, in that it allows you to design networks of genes activations. The advantage of the DB language over networks is that you can directly program a DNA, and that you can understand (with some effort) how a mutated DNA works.
2) the dna language has been designed to have a syntax reduced to the bone. This is because dnas are going to be randomly mutated, and a random mutation which breaks the code's syntax is just a waste of time. So, the syntax is very very simple, the only requirement is to preserve the cond start stop structure and to put comparison operators and commands in their respective place (that is, in the cond part and in the body part, respectively). There are no other rules.
3) the dna language has been designed to ensure a fair distribution of computational time between robots. The alife simulators allowing a traditional language, Tierra and Avida (I.e., they allow loops and subroutines) solve the problem of the distribution of cpu resources allowing each organism to execute only a precise number of _single instructions_ per cycle. The DB language allows the execution of the entire dna. You can have loops, but you have to split them in different cycles.
4) the resulting language is Turing-complete, in the sense that you can express with it whatever you can express with every other, more complex, language.
So, I perfectly agree with Shvarz. You can already do everything in the current language and whatever you may add to it will make it more difficult to mutate and decrease its evolvability. As for the subroutines (without cycles of any kind): they may be comfortable, but there's nothing you can't do with the actual system. Subroutines would create new problems, because they would break the linearity of the dna execution. They would be substantially macros, separated from the rest of the dna. Why don't you write an external compiler instead? Write a standalone program which receives as input a program in a more "comfortable" version of the DB language and produces a dna as an output. Could be very interesting from the point of view of programming combat bots.
Some other considerations:
I'd agree on making the syntax even looser by allowing to mix cond, start and stop everywhere in the code, as well as allowing the use of comparison operators and instructions everywhere. But this would be, after all, a minor change (and it would make the code much much more difficult to read).
I don't understand why you want so much to have junk dna. JUnk dna is dna which is not used and has no use. Being not used, it will become a total junk and will never by usable again thanks to a mutation. So its size will always increase, never decrease, and will never be useful to evolution. So tell me why you want junk dna so much (leaving apart the fact that there's already junk dna).