I think this behaviour is by design, though it’s less than ideal. Other editors have the notion of modal selection: line, column and linear, whereas sublime only has one (linear) selection that’s kludged to do all three. It’s engineered this way due to sublime’s multiselection/multicursor features.
The behaviour you describe is a function of the above design behaving intuitively when combined with, say, delete - if the caret didn’t move to the next line, delete wouldn’t delete the whole line, it would only empty the selected line.
Though I say “kludged” above in reality it’s not that bad, it just leads to annoying workflow inconsistencies. For example, if I press ctrl+l then shift+down x2, I’ve selected 3 lines. I then ctrl+c to copy, dump the caret on another line in my file and hit ctrl+v. What I want to happen is the 3 lines I copied to be inserted above the current line. What actually happens is the 3 lines are inserted at the current caret position, screwing up indents and generally not what’s wanted. To make things work right, I need to go to the line I want to insert above, hit up, ctrl+enter to open a new line, home to move to the beginning of that (blank) line, then ctrl+v.
Whilst it’s easy to be critical about this, I also recognise the potential clash between modal selections (line, column, linear) and multiple cursors/selections. I’m sure that with some thought it could be done well, but Jon’s opted for the KISS approach. Given the benefits that multiple selections/cursors brings, it’s a compromise I can live with, though I’d love to see an elegant melding of the two concepts.
Better macros (too limited atm) and a combination of simple plugin-style extensions could probably alleviate most of the headaches with the current model.