> 2) You can't put a change trigger on a cell or subset of cells, only on the whole sheet. So you have to manually check which cell the trigger happened on.
This is true of MS Excel's scripting language (VBA) as well. Worksheets are objects with events; cells are objects without (VBA-accessible) events.
But Google Sheets remote procedure calls are vastly slower than local OLE/COM dispatching. (And VBA/Excel presumably uses the optimized tighter COM interface binding instead of the slower high level COM IDispatch. Sure there's some overhead but it's nothing compared to Google Sheet's network overhead.)
Not only is scripting Google Sheets indeterminently and syrupy slow, it also imposes an arbitrary limit on how long your code can run, making a lot of applications not just inefficient but impossible. Running your code in google's cloud doesn't make spreadsheet api calls any faster, it just limits how long you can run, them BAM!
To get anything non-trivial done, you have to use getSheetValues and ranges to read and write big batches of values as 2d arrays.
It's easier to just download the entire spreadsheet csv or layers and bang on that from whatever language you want, instead of trying to use google hosted spreadsheet scripts.
This is true of MS Excel's scripting language (VBA) as well. Worksheets are objects with events; cells are objects without (VBA-accessible) events.
It may be an issue with scaling and efficiency.