Usually the cryptographic algorithms are considered most important for the blockchain functions, so they are implemented as precompiles first.
From what I understand, quite a bit of work and reasoning needs to be done about the effects of precompiles on the network. You don't want precompiles to be able to cause a denial of service attack on the network, where the precompile uses more computing resources that the gas properly accounts for. Having many precompiles also causes bloat inside of the EVM codebase that all validators need to run.
There is definitely potential to add more useful precompiles to the EVM in the future. I think the Ethereum foundation wants to take time and caution to make sure they are implemented correctly however.
Also, for things like binary search, or sorting algorithms, consider how smart contracts work in your implementations. It's often far better to expect a client to pass in a valid sorted list from offchain, then just do the verification that is is sorted onchain. The primary purpose of smart contracts is not to do heavier computational lifting, but rather to have a very reliable, trustable, and secure system people can rely on to trust in some programmable logic rather than trust each other.
A good rule of thumb is, if it can be created/a more complex algorithm can be run off chain, then the smart contract only has to verify the result is correct from whoever makes the call, that is a better implementation. A good example of this is merkle trees. We only store the root in a smart contract on chain, and a user who wants to verify something from the merkle tree passes in the proof to verify the data's inclusion in the merkle tree. You would never want to generate the whole merkle tree onchain, its just a waste of computational resources in most cases. Remember any code you run in a smart contract that is posted to the mainnet is repeated run and verified by thousands of nodes and validators to ensure correctness of the blockchain.