It replaces the standard [0,len()) with an [1,len()], though, which correspondingly makes other tasks easier. Plus it matches normal mathematical vector indexing.

In the end, in a language where you aren't doing pointer arithmetic, the sides are pretty even. We just tend to side with tradition, because it's easier to.

I found it uncomfortable when drawing on screen:

   y = margin + (i - 1) * lineheight

  y = 1 + ...

if y is 1-based too (which feels even more uncomfortable). But it would be nice to have such functions out if the box:

  canvas.linear_index(x, y, stride)
  vbox.y1_for(margin, spacing, height, i)
  vbox.y2_for(margin, spacing, height, i)

And then you have "integer at the center of a pixel" vs "integer at the top-left of a pixel" differences, which should be taken into account by these functions too. Stroke 1: y+0.5, y+height-1. Stroke 2: y+1, y+height-2. Fill: y, y+height.

Pixel geometry is hard on its own.

Off by ones happen with 0-based too (to me at least, at "write the new codez" stage). What languages are really missing is some stdlib for hiding these calculations under easily understandable names like nthfromend, nfromto, revidx, last, etc. Too much of n-1, n-i-1, -i-1, b-a+1, <, <= to maintain in correct ranges either way.

0/1-based are simply two degenerate around-off-by-one cases of working at general n-based offset, since both 0 and 1 are the most common results of off-by-one.