No sabía de los "quadtrees", pero si sólo importa la colisión del avatar y: Los enemigos y sus disparos, entonces no parece necesario, distinto es si los enemigos pueden colisionar entre ellos, con sus propios disparos, con los tuyos, los disparos colisionar con los tuyos, bloques, etc.

Deberías ver si ocurre siempre o porque con bajo rendimiento tu lenguaje se apura y chequea de forma menos exacta, ni idea, quizá ocurre siempre pero sólo lo notas cuando el juego está lento. Si los cuadros son más grandes que los objetos se detectarán colisiones inexistentes entre los objetos.

Yo pasé por problemas similares pero no me acuerdo mucho, abandoné el proyecto debido a otra dificultad, pero creo que recomendaría esto:
Supón que puede haber hasta 100 peligros en la pantalla. No hagas constantemente un chequeo de los 100 objetos. Ten una lista de cuales hay y chequea sólo esos. Puede ser algo complicado pues por ejemplo puede que se elimine el nro 3, no puedes "chequear el n, hacer n+1, repetir hasta...". Debes tener los números en un array y actualizarlo. Todo eso enlentece también, supongo que sólo es bueno si suele ocurrir que los enemigos son mucho menos que el máximo.

Sobre los quadtrees supongo que la pantalla se divide según dónde estén los objetos, si la división es fija y hay algunos en el límite podría fallar, considerar que están en una zona en vez de otra, el objeto A en la zona 1 y el B en la 2, pero están colisionando. Pero si los objetos son muchos puede ser muy difícil dividir la pantalla sin que una línea toque alguno, además que sean divisiones cuadradas o rectangulares...
Sino podrías hacer quadtrees fijos pensando en ese tipo de cosas, pero tendrías que ver en cuales está el objeto, agregarlos a un array correspondiente, y en algunos casos en más de uno.

En juegos como de Pool donde no puedes simplemente analizar colisiones de a pares (o sí pero sin alterar los valores, aún) o casos como que un disparo tuyo toca a una nave que te está tocando, se complica más.