The software function managing the 1-wire protocol generally has several non-interruptable sections in order to ensure the bus timings. This can make your processor unavailable for long periods of time.
Worse, some implementations do not allow any interrupt at all.
And even if your implemenation would allow being interrupted, it is generally blocking the main loop as it is not executed in an interrupt itself.
Using a hardware implementation for the 1-wire control instead of a full software would release the CPU from managing the timing and waiting for the 1-wire to complete. But such hardware implementation are not commonly available in microcontrollers.
There is however a middle way. An open source implementation using the microprocessor's or controller's UART to ensure the timings is available ( https://github.com/MaJerle/onewire_uart ) - MAXIM also has an application note for it ( https://www.maximintegrated.com/en/app-notes/index.mvp/id/214 ).
This also offloads the processor and it can be interrupt driven.
Is the processing slow because DS18B20 is on pin A0 instead of pin 2 ?
That might have an influence if the processor that is on your Arduino board would have a (partially) 1-wire compatible source on another pin, in which case the libary would have to take advantage of that.
Is there something wrong with the sensor itself?
That would not be generally the case, but in case you have two sensors on the same bus, the 1-wire protocol is slower as it needs to find all peripherals and the master has to indicate which one it is addressing.
Is it because of "This library"?
It is not because of that library, but there are other implementations (see the link above) that use hardware resources to improve performance at the cost of using a hardware resource (some MCU's have only 1 HW UART so you'ld not have a second one if you also need RS232 communication for instance on other signal lines).
