Yes rename is probably the way to go, however, you are assuming the date is the same for all jpegs which looking at the original code I would suggest is not the case.
Also, this would also depend on Slackware having the perl version of rename installed as the default version that comes with util-linux does not have the same level of ability.
So if we stick with the original example, you were close but forgot a golden rule in bash ... quote - quote - quote. If we were to take the first example file and place the output
into your script, the cp line would look as follows:
cp -p [01-10-12] 01.jpg `echo [01-10-12] 01.jpg | sed 's/.\(..\)-\(..\)-\(..\). /20\3\2\1_/'`
Now if we ignore what would happen with the square brackets, the fact that there is a space between ']' and '01.jpg' means that cp now sees this as 2 files and according to cp logic
if you are copying more than one file, you must be copying them into a directory ... which you are not as the renamed copy of your file does not exist as a directory ... hence the error
So here is your code with quotes and some changes to make it all a little more obvious:
for old in *.jpg
cp -p "$old" $(sed -r 's/.(..).(..).(..)[^0-9]*/20\3\2\1_/' <<< "$old")
Things I changed:
1. Double quotes around variable names to suppress any splitting on whitespace or any shell centric items being expanded (ie [0-9] means any of the number 0 to 9 can be in this spot)
2. $() in place of back ticks. Main reason is it is a lot more readable that guessing the difference between ' and `. Also, as your scripts get bigger and you may need to nest expansions inside each other and back ticks then become a nightmare
3. -r switch in sed just eliminates the need to escape the round brackets when saving information
4. The regex is up to you, but this version will not be concerned about the possibility of a space or not as per above post
5. <<< is a bash construct called a here document and I chose this over the echo just to keep the file name in its regular spot for sed (echo will also work fine)