Not gonna lie, that question is almost not something i'm qualified to answer, since I was more focused on specific ssl technologies/integrations, but I'll have a go.
Obviously they won't go away, but network appliances definitely won't keep their share because not everyone needs them as SDNs get better. I see the SDN and IDN as mostly solving multivendor integration issues and making it easier to configure at least semi-complicated networks, which doesn't make them a drop-in replacement for many of the problems f5 is trying to solve. For certain network loads they might achieve performance parity, too.
One of the draws for an f5 box for a large customer is that instead of having like 5 vendors or OSS technologies that they have to maintain for load balancing, ssl-termination, hardware-accelerated/-hardened encryption/decryption, SAML, firewalls, etc. you have one company's product (that hopefully has been designed to work well with itself) to do all of that that's configured from one location. If you don't have to worry about that multivendor orchestration headache, then massive network appliances like BIGIP aren't a value add over having a couple vendors.
Another draw for BIGIP is doing things at the speed of packet flow or nearly so even for VM containers and even for fully encrypted SSL. If you don't have to care about making sure to squeeze every last microsecond of latency or bandwidth out of you 10Gbs or 100Gbs fiber connection, BIGIP isn't a value add over SDN. If you only care a little bit, than an SDN could be way cheaper than BIGIP because you can configure things to do what you need for lower hardware and support costs.
For the people who care about that multivendor issue and performance, they're always going to have hardware dedicated to networking, even if they use SDNs or IDNs, because they need that dedicated compute to achieve their goals. Sustained 10Gbs connections are no joke, let alone 40Gbs or 100Gbs. Same with tens of thousands of simultaneous SSL connections. All of a sudden you need dedicated ASICS/"Raw Compute" and RAM to keep up with the firehose of packets. Plus, network appliances will begin to integrate with SDNs and IDNs, so for customers on the border between needing an appliance and a getting by with an IDN or SDN and more manpower, the form of the network appliance will change, but they're still going to have hardware down in their server room or compute instances in their cloud dedicated to networking infra. If you want SSL-termination? You need compute. Hardware accelerated or hardened SSL termination? You need specialized hardware. Firewalls? Compute. SAML? Compute. Complicated NATs? Compute. If you've got a couple BIGIPs in your server room, your network's complicated enough and/or bandwidth heavy and/or low latency enough that you're going to have nearly as much racks dedicated for your SDN so that it has enough compute as you do for network appliances.
BIGIP isn't valuable because it's great a router or switch. It's great because of how much it does on top of that in a single server/VM, and how well it does it. And most of what it's great at are not things that an SDN will solve. Sure, the configuration tweaking will have parity and maybe load balancing performance (but having seen how BIGIP achieves it, especially for complicated setups, i kinda doubt it). But if BIGIP integrates with SDNs or with IDNs even just a little, then what could happen is that people on the borderline are just going to get slightly smaller BIGIPs and offload some of the tasks where BIGIP overlaps with SDNs/IDNs and the BIGIP will just be another node in the SDN. If BIGIP goes in on SDN and IDN, then you might even see people buying larger BIGIPs to orchestrate their overall SDN and IDN.