What you are *selecting* isn't as important as what you are *scanning*.

If I have to walk to the shop to get an apple, then if the shop is 10meters away, I'll do it quickly. If that shop is 10miles away, it will take a long time, even though in both cases I'm just getting an apple.

If you are scanning a table that has the clob data interspersed throughout the rows, then isolating rows/columns that match your query predicates *still* has navigate through that clob data even if you are not selecting the clob column.

There are typically two common uses for LOBS.

1) "Small-ish" data, eg XML fragments, descriptions, etc etc. They are *mostly* 1000-4000 chars, but occasionally exceed that. So really you want something is like a "slightly bigger varchar2". For this an inline clob makes sense because you're treating the majority of the data like a varchar2, but catering for the occasional large ones. Forcing them out of line is going to cost you in terms of access (to the lob) because you'll be walking through a lob indexing structure to get content. Conversely, the raw table data is now a little slower to scan through because the LOB data is interspersed there.

2) Large data, eg, you are storing entire documents, or PDF files, or images and videos etc. In this case, just about every LOB is going to be tens of kilobytes, or megabytes in size. So now its the opposite of above - you *know* that any LOB access will be walking through the lob index structure anyway (because its such a large LOB) so you may as well keep it out of the row "entirely".

But dont forget...there are exceptions to *every* rule. Let's say your lobs are small *but* your application almost *never* accesses the lob - they are there for (say) annotative purposes. In that case, you might opt to have them out of line because they are so rarely accessed.