On https://www.chartjs.org/chartjs-chart-financial/ it's choosing increments of 10 which results in lots of whitespace (you need to change the dropdown to logarithmic)

I have a branch that works significantly better: https://github.com/benmccann/Chart.js/tree/log-scale-ticks
Unfortunately it fails more than a hundred tests that expect very specific ticks to be generated. We'd probably have to change the log scale tests to image tests in order to make any improvements to tick generation
The overall tick generation strategy for the log scale is not very well thought out. I believe that the wider range of data you have the more ticks it will generate. Instead we should do something like use LinearBase.getTickLimit to determine how many ticks can fit on the scale.
I'm removing this from the 3.0 milestone though because these are longstanding issues and shouldn't be a blocker for the release
I'm not sure what the most expected behaviour is. I believe the log scale expands the range down to the start of the power-of-10, i.e. the range is expanded down to start at 10 even if the data min is 30. I think the reason I wrote it that way was that usually log charts are used when the data range is very large and so expanding a bit isn't a problem. It generates so many ticks to out of the box generate something that looks like https://i.stack.imgur.com/zxKqo.jpg
We didn't have minor ticks as a concept when the log scale was introduced. Perhaps we could use that? Declare major ticks at 1, 10, 100, etc and then minor ticks in between. Before switching the generation options too much, I think its worthwhile to do a bit of research and see what other libs do
If you do a Google image search for logarithmic chart you can find lots of examples of how other charts are drawn. Very few begin at powers of 10 and for those that do it's typically because the data is near a power of 10, so you don't end up with much white space at the bottom of the chart. For finance chart examples you can try Yahoo Finance or TradingView as two popular sites that both offer log scales with interactive charts.
Here's an image where the data is far apart. We end up with probably too many ticks.

Here's an image where the data is close. We end up with not enough gridlines. I think it'd be easier to tell what the data points are if we had ticks at 10, 12, 15, 20 for example.

The two charts are the same number of pixels, so should show roughly the same number of ticks in my opinion. This is how the other scales we have today like the linear and time scale work.
Right, my comment was more around the first chart. If the data min is 20, I think starting the axis at 10 looks a lot better and is clearer to understand. That being said, there are too many ticks in the top chart and I think that's because the filtering is done in the label callback.
Perhaps we can apply the linear algorithm to the powers of 10. In the top chart, its equivalent to linear ticks at 1, 4, 7, ... which are easier to control. I'm not sure how to best control when to add minor grid lines. In the top chart, it would be cluttered, but if the range was smaller, I'd want to see grid lines at 10, 20, 30, etc.
Here's what it looks like starting at the nearest power of 10 vs not. I'm not sure I see any issues starting with 20. Doing so would be more consistent with the other chart types to have the tick range be close to the data range. I think starting at a power of 10 can make it look kind of squished with a lot of whitespace.
master

my branch

I like how the current code chooses numbers starting with 1, 2, 5. I had tried generating every number and letting the auto-skipper do its thing before, which would sometimes choose other numbers. That didn't look as nice because the numbers wouldn't be spread out appropriately when plotted
I like the results on your branch. How are you keeping the grid lines at 30 and 40 but not generating the labels?
It generates the ticks and then the tick formatter formats them as empty string. That's what happens in master and in 2.9. I didn't change that part
Is there anything we could do to make the test changes easier? I'm sure there are lots of old tests in the log scale that could be removed / simplified
I haven't looked too closely. I think a lot of tests probably test duplicate functionality and we could get away with removing most of them and replacing the rest with image tests. I don't really have more time to work on this though.