The general consensus within the WordPress ecosystem is that custom tables are bad and should be avoided primarily because they operate outside of the normal architecture of WordPress itself. Something like Pods offers a fusion of both, which lets you have custom post types / custom taxonomies, but powered by a separate table for their custom fields. It also integrates with the *_*_meta functions in WordPress, which WP core and other plugins utilize to interact with the fields, so the location being in a table is almost inconsequential.
The only drawbacks are that WP_Query meta references don't work, but we're working on that.
You could also go the route of Advanced Content Types in Pods, which are completely separate from post types, and live in their own table entirely. You create only the fields you need, etc..
For searching, I'm not sure the performance is entirely noticeable if you're on an optimized server / site utilizing object caching etc. Pods caches just like WordPress for it's data across the entire codebase, so that's something we've thought about deeply.
I recommend keeping to the standard Custom Post Types and meta-based field storage in most cases, but something you'll find is quite bad when filtering is that when you run a query in WordPress for 10 fields, that's 10 extra database SQL joins just for the meta alone, and that can really slow things down when you have a lot of data.
As you saw in our diagram, sometimes you just can't beat the performance of a well architected content type table.