The Enterprise geodatabase model (there is no SDE, only Zool) was originally based on the ODBC model, which only supports tables. No RDBMS supports "folders," it's just database.schema.tablename, so any folder organization would have to be implemented in metadata, which may not be standardized across clients (non-geodatabase, JDBC, ODBC,...), and then you have nightmares like dataset corruption because SQL was used to DROP a table and the metadata was not scrubbed (this is the reason that command-line ArcSDE tools were eliminated after 10.2 -- too much data corruption "using Esri tools").
99.9% of the time that customers complain about locks interfering with schema change operations, it's because they didn't realize that placing 40 feature classes in a feature dataset meant that any use of any of the FCs generates READ locks on all of the FCs in the FDS. So yes, there's a performance penalty, but more importantly there's a functional complexity penalty. You can't get simpler than a list of table names out of the system catalog. The price is paid for a topology because it's worth what you gain, but I find one level of folder organization to be a paltry gain for what it costs.
- V