Your tile editor is not that intelligent. If you want to think of it as a hex editor with a very odd decode function then that would not be the worst thing you can do.
"2bpp format on all set of 16 bytes from start to end" is pretty accurate here. Many tile editors will allow you to change this start address, probably at a bytewise and maybe even bitwise level (something like tiled2002, http://home.arcor.de/minako.aino/TilEd2002/
, combines the larger byte/whole tile jumps with the smaller ones), many others will allow different decode methods and a precious few (mainly something like crystaltile2) will allow you to skip a number of bits per tile in case you have a per tile header or something -- such a thing is practically unheard of in the NES world but happens enough to warrant the functionality at least on the DS. Equally some might have some minor awareness of NES ROM formats and even mappers but nothing close to any kind of heuristics or pattern analysis like you might see for audio programs at times. Likewise the NES is a bit more limited in what it can do with graphics and slow enough that compression is not terribly common so you can set default decode methods to be luckier more than "start at 0" might afford, you lose this as you go more generic and get something like http://www.romhacking.net/utilities/646/
but at the same time it is far more extensible.
"a tile editor could read the data backwards and process the 16 byte sets all the way though without scrambling them"
I am not sure quite where you are going with that but it was either a slight lead on from above or a lead into either optimisation. Maybe back when it might have mattered but today. Start from the back is also a way to dodge flash cart header/alignment issues but at the same time if you advance one pixel at a time you will very shortly at least hit a multiple/natural divisor of the right number.