Can running a query on a readable secondary slow down (block) the primary in AG
In Simple terms..


  Readers won't be blocked by DML operations,but there is a chance of blocking with DDL operations..


This not blocking  is achieved by mapping isolation levels to snapshot isolation levels.As a result of this,there will be row versioning over head,but there won't be any blocking by DML(Insert/Update/Delete)..

See below for more details on how Isolation levels are mapped in various cases   




  What can happen is that the REDO-thread is blocked by a long running query => changes can't be applied to the secondary


When there is a blocking on secondary due to lock conflicts (thread trying to apply DDL to a page generated on primary ) and redo thread is blocked.The only impact i could see is log growth (depending on synchronous commit or asynchronous commit). But there will be blocking irrespective of sync model you choose.

SQL team, even tried with a design  option of killing read only query on secondary automatically,when there is blocking ,but went against the option..

Below is the explanation from Sunil Agarwal on the same


  When we were designing this feature, we thought about killing the redo work -- sorry, killing the reporting work automatically. As soon as redo is blocked, we'll say, okay, I'm going to kill the read workload, and the redo moves forward.
  The problem was if you were running a reporting workload that is very critical for now or your reporting workload was taking half an hour to run and you were almost like 39 minutes done and the blocking happens and if you kill it, it's not a good user story.So what we have done is we have exposed the right knobs and we let the customer decide what to do if the redo thread gets blocked.


so you will have to monitor Xevents to know about blockings and take decision

References  used:
AlwaysOn Solution Guide: Offloading Read-Only Workloads to Secondary Replicas
AlwaysOn: Impact of mapping reporting workload on Readable Secondary to Snapshot Isolation