RFC 2945 By Tom Wu the SRP inventor uses
x = H(s, H(I, ":", p)) where
I is the username demonstrating that can do anything you like to the stretch the password such as prefixing the username then hashing it. So stretching the user entered password before putting it into function using PBKDF2 would increase the time taken for a dictionary attack with no effect on the strength of the protocol e.g.
x = H(s, PBKDF2(p))
(Edit Note the design document uses
x = H(s, p) but the SRP-6a paper linked to from that page uses
x = H(s, I, P) so both differ from the RFC.)
PBKDF2 throughout the protocol would slow down the server drastically. With an online dictionary attack you want the attacking client to run slow without it tying up server resources. This suggests only slowing down the
x function whilst keeping a good hashing function like
SHA256 or better throughout the rest of the protocol. Also as @otus points out in a comment with an offline attack on a captured verifier they don't need to run the full protocol only the steps to generate the verifier. Again this means that there is no benefit to slowing down the full protocol.
x function to only use the key stretching algorithm with
x = PBKDF2(s, p) seems illogical. You have to use the
H algorithm to run the rest of protocol using the fast
H the server is running. The purpose of running the key stretching algorithm is to slow down the client so you may as well use both
PBKDF2 by using the RFC function for
x but stretching the raw password then passing into the RFC function giving
x = H(s, H(I, ":", PBKDF2(p))).