This is a very common thing to do in an iRule and unless you have a severely loaded BIG-IP you shouldn't have an issue.
If you're concerned, you can turn on iRule timings to see how many CPU cycles are being used by the rule. DevCentral has an old but good article on how to do this. The only out of date part is on v11 you'll want tmsh instead of bigpipe (e.g. "show /ltm rule").
If you really want to avoid iRules, an alternative method is HTTP Class (Local Traffic > Profiles > Protocol > HTTP Class) however this classifies by URI and not source IP. It gives you the ability to send matching URIs to a different pool or return a redirect. You could combine this with the new Source attribute on Virtual Servers in v11.3 to make multiple Virtual Servers that each only handle traffic from a particular network.
However if you have many source ranges to cover, I'd just use an iRule and an address type Data Group (use the "match class .. equals" command to search for the client IP in the Data Group a bit like you would with a routing table).
Packet Filters are brutal and will cause timeouts to the client, whereas the HTTP Class or iRule options let you choose whether to drop the request, choose a different pool, return a redirect, or return an error page.