There are at least 2 problems with this question:
1. too general (what do you mean by numbers only etc)
2. you should avoid making things more complicated than they are
About #2, if you know that for instance a mask like ?d?d?d?d?d together with --increment works perfectly for you, then you do not need to worry about it...
On the other hand if you work w/ so-called slow hashes (i.e. for instance sha512crypt, grub2 etc) and you want to test 2 or more very, very specific masks, then using a .hcmask file makes perfect sense (well, maybe you do not usally run huge mask on those slow hashes anyway).
So think like this:
if you really, really need to run oclHashcat on your command line more than 1 time, w/ 2+ very specific masks, then using a .hcmask file could help, i.e. oclHashcat doesn't stop after the first mask but will run 2+ masks one after the other.
If you instead can use --increment to do the exact same task, then go after it.
For your specific case:
Consider for instance that you want to run only exactly 2 masks (nothing more than those):
?d?d?d?d
and
?d?d?d?d?d?d
This is not possible w/ --increment only since also ?d?d?d?d?d will be run (even if you use --pw-min and --pw-max).
Instead if you use a mask file with those four and six-digit long mask, you would avoid:
1. that you need to start oclHashcat more than 1 time (e.g. 1st time w/ length 4, 2nd time w/ length 6)
2. if you use --increment, also length 5 will be checked, and we said that we want to avoid this (in this specific example)
So those paragraphs above also somehow describe problem #2 about your question. It really depends on what you really need to run, which masks you want to include/exclude etc.
The general rule is, if you can avoid using a .hcmask file by using --increment or other means, then you really should avoid it (even if it doesn't hurt in general, we didn't measure any overhead at all). But it may make the command line more simple and you also can change the mask directly on the command line if you need. keep it simple
On the other hand, collecting very good working masks within some .hcmask files (with reasonable names etc) is also a good idea. See for instance the /masks/ of your oclHashcat folder. The idea here is that you run the best-working masks first, so you prioritize some masks over others, but at the end for instance cover the whole keyspace that you want to "test". This most probably doesn't make much sense with digits only but when it comes to a larger keyspace (with positioning of special characters etc for instance), then it perfectly makes sense to run the "reduced" keyspace first.
In your case, in general it doesn't make much sense to fix for instance some digits to a constant value e.g. 15?d?d?d (and change 15 to other values with different masks later on), instead it could reduce speed in some cases heavily. So avoid it if you aren't sure that "15" must be at the start of the password. Again, things may change if the mask is longer and/or if you use slow hashes. But also here you shouldn't introduce masks that only reduce keyspace but you aren't sure that cracks are very likely.
1. too general (what do you mean by numbers only etc)
2. you should avoid making things more complicated than they are
About #2, if you know that for instance a mask like ?d?d?d?d?d together with --increment works perfectly for you, then you do not need to worry about it...
On the other hand if you work w/ so-called slow hashes (i.e. for instance sha512crypt, grub2 etc) and you want to test 2 or more very, very specific masks, then using a .hcmask file makes perfect sense (well, maybe you do not usally run huge mask on those slow hashes anyway).
So think like this:
if you really, really need to run oclHashcat on your command line more than 1 time, w/ 2+ very specific masks, then using a .hcmask file could help, i.e. oclHashcat doesn't stop after the first mask but will run 2+ masks one after the other.
If you instead can use --increment to do the exact same task, then go after it.
For your specific case:
Consider for instance that you want to run only exactly 2 masks (nothing more than those):
?d?d?d?d
and
?d?d?d?d?d?d
This is not possible w/ --increment only since also ?d?d?d?d?d will be run (even if you use --pw-min and --pw-max).
Instead if you use a mask file with those four and six-digit long mask, you would avoid:
1. that you need to start oclHashcat more than 1 time (e.g. 1st time w/ length 4, 2nd time w/ length 6)
2. if you use --increment, also length 5 will be checked, and we said that we want to avoid this (in this specific example)
So those paragraphs above also somehow describe problem #2 about your question. It really depends on what you really need to run, which masks you want to include/exclude etc.
The general rule is, if you can avoid using a .hcmask file by using --increment or other means, then you really should avoid it (even if it doesn't hurt in general, we didn't measure any overhead at all). But it may make the command line more simple and you also can change the mask directly on the command line if you need. keep it simple
On the other hand, collecting very good working masks within some .hcmask files (with reasonable names etc) is also a good idea. See for instance the /masks/ of your oclHashcat folder. The idea here is that you run the best-working masks first, so you prioritize some masks over others, but at the end for instance cover the whole keyspace that you want to "test". This most probably doesn't make much sense with digits only but when it comes to a larger keyspace (with positioning of special characters etc for instance), then it perfectly makes sense to run the "reduced" keyspace first.
In your case, in general it doesn't make much sense to fix for instance some digits to a constant value e.g. 15?d?d?d (and change 15 to other values with different masks later on), instead it could reduce speed in some cases heavily. So avoid it if you aren't sure that "15" must be at the start of the password. Again, things may change if the mask is longer and/or if you use slow hashes. But also here you shouldn't introduce masks that only reduce keyspace but you aren't sure that cracks are very likely.