I wouldn’t have thought it would be an “Engine Bug”. And to repeat what @geometricalC2123 said, it’s perfectly normal to expect performance issues when using something like GetPartBoundsInRadius with 50,000 parts in one place
The reason that this doesn’t work well is that the whitelist / blacklist actually has to be fully evaluated into a flat set of BaseParts with the current raycast / region query implementation. That is, before the query begins, all of the descendant BaseParts which are included by the whitelist / blacklist have to be identified and added to a set that will be used by the query.
This works more efficiently than lazily evaluating whether candidate BaseParts should be ignored by looking at their ancestry for the typical query, but hits a performance cliff once you reach a certain number of BaseParts included by the whitelist / blacklist.
The resolution is that you should avoid filter descendants lists which include an excessively large quantity of parts (directly, or indirectly through being descendants of one of the items).