One particularly common performance pessimization is replacing an algorithm with one that has better big-O performance but a worse constant factor, and doing so where the particular O is much smaller than the number of times the function is called. People learn that hashmaps are O(1) while red-black trees are O(log N) and linear search is O(N), so they'll default to using a hashmap for a lookup table, even if the lookup table has 10 items but the keys are ~500 byte strings. (I'm guilty of this one myself, but at least I measured and fixed it.) Then they'll call this lookup in a loop 5000 times.
Using Python or another rapid-prototyping language can be a good idea here if you take the time to profile and identify the bottlenecks, but very frequently you end up shipping it, throwing hardware at it, and then wondering why you're spending hundreds of thousands of dollars on AWS bills. Plus, a really big problem with many common Python architectures is that they use pure Python libraries & frameworks even on the critical path. (Big offenders here include using BeautifulSoup in your 1B-page web analysis or Django on your million-user website.)