I would certainly agree that any process where you end up disclosing the private key to third parties should be avoided, considering that the CSR would suffice (see https://gethttpsforfree.com/). “Disclosing to third parties” to me includes scenarios where the client might be generated client-side, but there’s no way to verify this without auditing the entire code base (and making sure you’re actually being served what you were auditing).
That being said, this is something that other CAs do too (e.g. StartSSL - and yes, that’s not a 1:1 comparison since this is a “random” site), so I wouldn’t be too harsh about it. I would at least add an option to provide a CSR and only optionally allow the private key to be generated in the browser (after appropriate warnings).
With regards to the discussion about the client being written in Python: I think it’s a good choice for Linux, which runs the majority of web servers. As for Windows, the deployment story there might not be as good, but it’s certainly possible to run python on Windows. The decision to focus on Linux support, and support for apache and nginx initially absolutely makes sense given the market share of those stacks. Luckily, ACME doesn’t have any lock-ins with regards to operating systems or web servers, so there are plenty of third-party clients with better support for Windows, written in languages that are more easy to deploy on Windows, and that support typical Windows environments way better (i.e. IIS). It would be silly to implement the official client in a .NET language, which is comparatively harder to deploy on the most commonly used OS for web servers.