Why is converting 0-indexed code to 1-indexed code non-trivial?

It's still trivial. Everywhere you have a(something) you change it to a(something+1).

Leave n alone. Even n before is still even n after, but it affects an odd array element, because you changed a(n) to a(n+1).

You can then simplify the mathematical expressions if you wish. It's the simplification that is non-trivial.

I understand that OP is looking for a canonical answer to the following question:

Why is converting 0-indexed code to 1-indexed code non-trivial?

But there can be no answer to this question (canonical or otherwise) because, as has already been noted in some other answers, the conversion process is trivial. I will provide a particularly simple description of it in order to emphasise the point, and to pursue another angle that does at least provide an answer for another question the OP asks.

Say you are required to work in a language with 1-indexed arrays (such as Lua, Julia, etc) but your algorithm is described in terms of working on a 0-indexed array which, for the sake of argument, let's call A.

Define two functions:

function get_A(index)
    return A[index+1]
end

function set_A(index, value)
    A[index+1] = value
end

Now, everywhere your algorithm fetches a value from A at some index, call get_A with that index instead. And everywhere your algorithm updates the value at some index in A, call set_A with the index and the new value instead.

If other operations, such as those based on slices, are required, they can be constructed in the same manner as get_A and set_A.

Several of the other answers mention refactoring, but refactoring is a bit of a red herring. It is only required if the performance you get when using these functions is insufficient for your needs -- and bear in mind that many optimizing compilers are quite capable of inlining functions like these and producing efficient code from them. In cases where readability for sake of assurance of correctness is more important than performance, it would actually be wiser to not simplify the expressions in the source code.

In that light, to give an answer for the other question:

What, fundamentally, is preventing the creation of a foolproof set of guidelines for adapting such code?

What's preventing it is that sometimes clarity trumps performance and sometimes performance trumps clarity, and since we can't guess which is going to be the more important requirement for any particular piece of software, and we can't guess how good the chosen compiler is going to be at optimizing the arithmetic under the hood, we can't create a single set of guidelines for adapting 0-indexed code to 1-indexed code that could reasonably be called "foolproof".

Get a book about refactoring.

First step: You replace an array with indices from 0 to n-1 with an array with indices from 1 to n, and add 1 to every array index.

Second step: If you have a loop where an index used in this array runs in the range k1 ≤ index < k2, you change the range to k1 + 1 ≤ index < k2 + 1, and subtract 1 from every use of index. That should remove the "+1"s you used in the first step.

Third step: Wherever an index is calculated, or wherever it is passed to a function, add 1 to the index and subtract 1 where the index is used.

Best not to do this alone, but to have a colleague doing the exact same thing; then you diff your results and they must be identical. Be disciplined and don't touch anything else. Do a small number of changes, and when you and your colleague agree, commit one of them. If you don't agree and can't figure out where you went wrong, throw it away and start over.

TL;DR

A programming language that uses one-based indexing imposes the condition that zero (0) is not a valid index for the language's built-in array type (or, matrix type).

Programming languages generally do not restrict the range of integer arguments passed into functions and data structures. In other words, function calls and data structures are generally not required to follow the one-based indexing rule.

Many programming languages encourage the convention that functions and data structures should mimic the way arrays work whenever applicable, so as to save the programmer-user from having to determine what convention to use every single time.

Whenever it doesn't make sense for certain functions and data structures to mimic a built-in array's behavior, then don't.

It is, therefore, the responsibility for a programmer proficient in that language to figure out how to implement what needs to be done in a least burdensome way.

A programming language that uses one-based indexing will generally need to specify how to resolve these issues idiomatically.

Code sample in MATLAB:

% someVector is a MATLAB row vector
someVector = zeros(1, 6);

if true
    % valid MATLAB code
    someVector(1:6) = -1:-1:-6; 
else
    % invalid, matrix index cannot be zero
    someVector(0) = 0.99; 
end

%% ......

% someFunction is a MATLAB function
function result = someFunction(a)
    if a == 0
        result = 0.99;
    else
        result = -a;
    end
end

% Zero is a valid value when used as a function argument
b = someFunction(0);

%% ......

% MATLAB has a dictionary type too.
cm = containers.Map('KeyType', 'int32', 'ValueType', 'any');

% Zero is a value in int32. It is valid to use zero as a key.
cm(0) = 0.99;

A prime example is the Fast Fourier Transform (an implementation of Discrete Fourier Transform), or more generally the representation of any signal processing code.

Each element of the array is supposed to represent the coefficient for Z0, Z1, Z2, and so on.

It is obvious that MATLAB's one-based indexing will cause tremendous trouble to the novice user, because the coefficient for Z0 cannot be stored in a vector at index 0. It can only be stored at index 1.

Yet, MATLAB users simply swallowed their complaints. A convention has evolved that every dependent (signal) variable should have a corresponding independent (domain) variable, and that nobody should assume that the values inside an independent variable starts at one.

In the following MATLAB code example, a vector (sequence) named k is created as the input to the mathematical function "z raised to power k". The output is saved in a vector (sequence) named 'y'.

Observe that, the elements in y and the elements in k are in correspondence. Instead of expecting that y(30) containing the value z30, a MATLAB user first finds the element in k that contain 30, then finds the corresponding element in y. A typical usage is thus

y30 = y(k == 30);

Such usage may look tedious, but it is largely hidden from the everyday user's view because they are taken care of inside library functions.

One could argue that this is computationally inefficient. The one-line code above entails a whole-array equality comparison in order to find the index of the element in k that equals 30, and then use the index to read the element from y. (If the array length is one million, and a programmer uses this one-line code a million times, the time complexity is proportional to one million squared.)

_{(Disclaimer: The following example is intended to illustrate the array indexing issue. It is not intended to illustrate signal processing concepts.)}

% vector length
n = 128;

% a row vector of length 128, with content 0, 1, 2, ... 127
k = 0 : n-1;

% let's create some complex number
z = exp(0.005j);

% let's compute z raised to the power of something
y = z .^ k;