Complementando mais um pouco...

A ideia do TemporalAccessor é ser uma interface bem básica que define uma maneira genérica de obter os valores numéricos correspondentes aos campos de data. Tanto que os únicos métodos que vc precisa implementar recebem um TemporalField, e um indica se o campo é suportado, enquanto outro retorna seu valor.

É a funcionalidade mais básica, que permite que se obtenha qualquer campo de uma classe que represente datas/horas, quando suportado.

Já a interface Temporal adiciona métodos para modificar campos (na verdade, para retornar outra instância modificada, já que as classes do java.time são imutáveis) e somar/subtrair uma unidade de tempo.

Mas na documentação de ambas diz para evitar usá-las diretamente - salvo raras exceções, e de fato na prática eu acabo usando tipos específicos para cada caso (LocalDate, ZonedDateTime, Instant, etc). Inclusive, os getters de cada classe são mais fáceis de usar do que o get genérico de TemporalAccessor (que também quase não uso na prática).

Sobre o histórico de offsets, podemos fazer um pequeno código para ver a diferença. Primeiro com um timezone:

// obtém a lista de mudanças de offset
List<ZoneOffsetTransition> mudancas = ZoneId.of("America/Sao_Paulo").getRules().getTransitions();
System.out.println(mudancas.size()); // 91
for (ZoneOffsetTransition tr : mudancas) {
    System.out.println(tr);
}

A quantidade exata de mudanças vai variar conforme a versão do Java e do TZDB que estiver instalada, já que isso é sempre atualizado. Mas enfim, no timezone America/Sao_Paulo tem uma lista bem grande de alterações.

Agora se usarmos um offset:

List<ZoneOffsetTransition> mudancas = ZoneOffset.ofHours(-3).getRules().getTransitions();
System.out.println(mudancas.size()); // 0
for (ZoneOffsetTransition tr : mudancas) {
    System.out.println(tr);
}

A lista terá zero mudanças, e o for não vai imprimir nada. Isso porque o offset é fixo, nunca muda.

Aliás, essa é uma das pouquíssimas API's que fazem esta distinção. A maioria simplesmente assume que offset é o mesmo que timezone e acabam ficando incompletas e até mesmo incorretas. Não é raro ter apenas uma única classe para ambos (isso quando tem, pois há API's que nem sequer permitem manipular o timezone).

Eu particularmente considero o java.time uma das mais completas e bem pensadas API's de data existentes, por esse e vários outros detalhes.