As mentioned in the comments, bcrypt is a password hash, and has significant limitations compared with a general cryptographic hash function.
Using it as intended, for password input, but with the salt the same as the input, is as secure as using no salt at all. The purpose of the salt is to prevent multi-target attacks and prevent the use of rainbow tables. If the salt is the same as the input, this allows those attacks, since an attacker now knows what any salt will be for a given target password.
Using it as a general hash function runs into a completely different set of problems, the worst being collisions. bcrypt has a 72 byte input limit on the input text, if you hash large pieces of data it will have the same hash as its 72 byte prefix. bcrypt also repeats short inputs until it fills the 72 byte state array, so an 18 character password will have the same output as that password repeated 4 times. Implementations may pre-hash the input with something like SHA-512 before it gets to bcrypt, which prevents those issues. Though in that case, even though it is slow, its output is still only 192-bits in length, which substantially limits its collision resistance for use in things like digital signatures.
With all of those limitations, there are clearly better options if you want to slow down a hash function, the most obvious is to just repeatedly run the output of the hash function through again. This is also less complex than bcrypt, and can allow you to reuse already existing functions in both software and hardware. If you are concerned about getting stuck in a hash chain for some reason, you can always add a simple iteration counter word to the input. For some parameterized hash functions you can also increase the internal round count. Keccak for example can easily be extended to use more rounds, some implementations that generate round keys algorithmically may only require the change of a single line of code.