The two pinmapping options just choose which pins_arduino,h is used. They do not require burn bootloader to take effect, it's just a compiletime option.
tldr: Pick clockwise on the tiny84 for all new code, it is strictly better. Don't use the CCW mapping unless you're working with existing code that was written for the counterclockwise mapping
While Arduino works in pin numbers, internally the chip has two "ports" PORTA and PORTB, and each port has three registers associated with it. PORTA controls 8 pins, PORTB controls 4 pins - each pin corresponds to a certain bit in those registers, ex, PA0 is bit 0 in DDRA, OUTA, and PINA, PA5 is bit 5, etc.
So given that, the core has to have a way of converting pin numbers into the port, bit form that the hardware uses. This is done with a series of lookup tables, with names like digital_pin_to_port, digital_pin_to_bit, digital_pin_to_timer, and so on. That means that the core author has the power to specify an arbitrary mapping of pin numbers to actual pins. For most parts, there is one way of numbering pins that is obviously the best. For example, on the tiny84, if you start going clockwise from the power pins, you'll go through PORTA from 0-7, then PB2 (gaah), RESET (PB3), PB0, PB1. So PB2 is pin 8, we skip the reset pin (this is almost universal for Arduinos - you always skip reset in the pin numbering, and then assign it the last number), PB0 and PB1 are 9 and 10, and PB3/reset gets 11. That is the smart way - it has an added bonus too - if you're using a crystal, that goes on PB0 and PB1. Then there are three pins unavailable for GPIO. Since they're the highest number pins, you're left with 9 available pins numbered 0-8, and if not using a crystal, you have 11 pins, numbered 0-8, then skipping the reset pin 9-10. These are both really sensible.
A less smart way is going the opposite direction. Not only does this make calculations harder (hence slower and bigger binaries), if you're using a crystal, the pin numbers of pins you can actually use will start at pin 2, since pin 0 and 1 are used by the crystal. There are no advantages to the CCW mapping. It is technically and aesthetically worse. It is only there to support legacy code.
The reason, beyond aesthetics, that the numbering matters is that in addition to the lookup tables, there are other function needed, to, for example, convert between analog and digital pins - these sort of things are done internally by things like analogWrite, digitalWrite and so on. This is usually not done with a lookup table - As long as the pin mapping that the core author chose is not really stupid, there is enough order in the way pins with analog input are distributed that this function can be small, fast and efficient. In the case of the tiny84, the clockwise version makes these very simple. There counterclockwise one, besides being ugly, requires more math to be done there.
Both ways saw widespread use, unfortunately. Thus, to make sure people can use code they wrote with other cores with ATTinyCore without modifying the pin numbers, we include the option to use either pin mapping. For new code, you should always use the default pin mapping option.
There are a few other parts with multiple pin mapping options like that. And in the next release there are going to be, uh.... more.... The t1634 - it's my fault, can't blame anyone else for this - I made that pinout, but I did it when I was inexperienced, and the result is dumb. So the 1634 will have a second option (which will be the default).
The 167/87 ends up with 3 options, 1 smart one, and 1 stupid one to match available digispark pro boards, and one that has been used on other cores in the wild, and is the work of a smart but malicious being (if it was a human, I think demonic inspiration was involved). That last one is so thoroughly perverse that I couldn't do the analog pin <-> digital pin conversion without a lookup table. Code size is smallest and execution time shortest on the smart pinout, the digispark one is slightly worse, and the legacy one... is markedly worse.
There are a few others, and 2.0.0 will add a couple more (and will generally be better in every way, sometimes greatly so). It'll also add a bunch of defines of the form PIN_Pxn where X is the port letter and n is the pin number, so you can write code that doesn't care what the pin mapping is - the PIN_Pxn will be replaced by the right pin number, regardless of what the pin mapping says. I've sort of leading a holy war against using numbers as pin identifiers instead of PIN_Pxn - unfortunately until 2.0.0 is out, those aren't available on ATTC.
Sorry for the wall of text!
As for the issue of programmer - yeah, you need to use the slow mode when you first burn bootloader to tell it to run at 8 MHz instead of 1MHz (though on some tinyISP's it doesn't work correctly 
bad fw on the tinyISP). I believe ArduinoAsISP does default to a slow enough speed that it will work, but I don't know for sure off the top of my head
