There is always an overhead, but it's quite small. I would say that annotating EJB's as transaction's NOT_SUPPORTED is more important for the readability and maintenance of the code than the performance.
But there are some cases where it could lead to performance bottle neck, like distributed transaction and remote objects. I've heard once that great companies like Google does not use distributed transaction because of this, that they use transactions just at low-level granularity (to ensure small chunks to be executed together).
I really don't know and haven't read or experienced such kind of issue, but it makes sense because nowadays we want to abstract our infrastructure and balance the load among several nodes. Imagine a horizontally distributed environment with distributed transaction two-phase commit. Or worst, imagine the transaction manager having to synchronize everything and having to ensure ACID in a distributed environment.
This kind of issues and questions lead to solutions like cloud computing, grid computing, BASE transactions, NoSQL, CAP theorem, etc. That's a nice topic that I want to go deeper!
Feel free to ask me anything!
www.BlackBeltFactory.com/ui#!/ref=jmotta, SCJP 6, OCWCD JEE5, OCE EJB JEE6