I have Ardupilot on plane, using 3DR Radio back to Raspberry Pi on the ground doing some advanced geo and attitude based maths, and providing audio feedback to pilot (rather than looking to screen).
I am using Dronekit-python, which in turn uses Mavproxy and Mavlink.  What I am finding is that I am only getting new attitude data to the Pi at about 3hz - and I am not sure where the bottleneck is:

3DR is running at 57.6 khz and all happy
I have turned off the automatic push of logs from Ardupilot down to Pi (part of Mavproxy)
The Pi can ask for Attitude data (roll, yaw etc.) through the DroneKit Python API as often as it likes, but only gets new data (ie, a change in value) about every 1/3 second.

I am not deep enough inside the underlying architecture to understand what the bottleneck may be -- can anyone help?  Is it likely a round trip message response time from base to plan and back (others seem to get around 8hz from Mavlink from what I have read)?  Or latency across the combination of Mavproxy, Mavlink and Drone Kit?  Or is there some setting inside Ardupilot or Telemetry that copuld be driving this. 
I am aware this isn't necessarily a DroneKit issue, but not really sure where it goes as it spans quite a few components.
Requesting individual packets should work, but that was never meant to be requested lots of times per second.  
In order to get a certain packet many times per second, set up streams.  A stream will trigger a certain number of times per second, and will then send whichever packet is associated with it, automatically.  The ATTITUDE message is in the group called EXTRA1.
Let's suppose you want to receive 10 ATTITUDE messages per second.  The relevant parameter is called SR0_EXTRA1.  This defines the number of Attitude packets sent per second.  The default is 4.  Try increasing that parameter to 10.
ArduPilot, Dronekit-Python, Mavproxy and Mavlink - Hunt for the Bottleneck