Sort:  

It definitely takes an understanding of the software/network but is certainly safe for use. There's just shy of 1000 BTC in public channels using the network, not even counting private channels, so if it was risky then those would have been compromised long ago. As for the different implementations they all share the same BOLT specs and would all be interoperable for the main needs of an exchange.

This would also be an excellent addition to being a fast ramp for users into Hive. By using Strike by Zap, a US user would be able to buy Hive via fiat in their bank account for only the cost you would charge them for the BTC to Hive conversion. This whole transaction would settle in less than 15 seconds.

It would also mean that you can batch all withdraws you need to the exchange you use as a single onchain transaction versus paying with multiple UTXO with on chain payments. That might not be a huge saving today but wait till transaction costs go back up. It'll be much better to be prepared today IMHO.

I won't say there won't be huge improvements ahead but Lightning Network is already ready for the task. The first exchange to provide it will have a great headstart with building a regular userbase and mindset for using the tech.

Would you suggest any python libs / api that would allow to use it? So far I didn't find anything plug&play.

I'm not as familiar with python but I believe PyLightning would be up your alley for that.

To get a node up and running easily I would recommend BTCPay. It includes the option for a lightning node and makes setup very easy. I've always used LND with it but with that library you'd want to go with clightning which I'm a bit less familiar since I've been only been using LND for some time now.

The hardest part with lightning is managing the channels of your node. I'm not sure how familiar you are with lightning but everything runs off payment channels. If a channel is full then it can't receive payments and users will have trouble routing payments in. I usually recommend Lightning Loop when using LND but not sure of a comparable alternative in clightning. Nonetheless I'm sure for smaller transactions it would still be cheaper if you had to close your channels if they fill up.