Thanks for a bug report. Accounts configured through GNOME Online Accounts are updated with the server-side values, including the color where applicable (if provided by the server, which is the case for the Google accounts).

I can make such change, no doubt, but would it make more sense to change the color on the server, thus any other computer which connects to the same calendar will also use the same color, thus it'll be consistent across machines and even the Web UI of the Google calendar?

Except that the calendar colors don't match the settings I have on Google Calendar, either, which is the reason I went to set a custom color on the calendar to begin with.  Oh, the color Evolution sets is the color that the calendar was set to when I added the account, but it hasn't picked up the change I made on Google, nor will it persist the change I make in the Evolution UI.

I see. I checked the source code and the color is meant to be changeable by the user. I thought it's opposite, I'm sorry about that. That is, the color specified on the server is used only if the calendar had been added for the first time. Then it's all up to the user. I did think it's more logic to keep in sync the color on the server as well, but it had been changed few years ago [1].

It takes us back to the original issue, why does it change the color for you, even when you changed it in the UI?

It looks like the saving failed for some reason. I tried it locally and even after restarts of the background processes the color I chose in the UI sticks. I even changed the color on the server, to see what it'll do.

Could you try these things, please?
a) close evolution
b) open a terminal and run there:
   $ ESR_DEBUG=1 /usr/libexec/evolution-source-registry
c) open another terminal and run there:
   $ evolution
d) change the color of one of the affected calendars

At this moment, the console with evolution-source-registry will show some changes in color, like here (many surrounding lines skipped):

   : [Calendar]
   : BackendName=caldav
 - : Color=#4e9a06
 + : Color=#5c3566
   : Selected=true

Then use evolution as before, and wait for the color revert. If there is no such line on the evolution-source-registry console, then check whether there's anything shown on the evolution console, like runtime warnings or basically anything new.

Thanks in advance.

[1] https://git.gnome.org/browse/evolution-data-server/commit/?id=f4fb3c7f077a43d0d5bc

Color change showed up in the debugging run of evolution-source-registry:

   : [Calendar]
   : BackendName=caldav
 - : Color=#ab8b00
 + : Color=#ea0a8e
   : Selected=true

I'll update in a day or so when I find out if the color change stuck…

Oddly, it seems to have taken this time around.  I suspect a difference between the debug mode and non-debug mode, because another artifact was that changes I made directly to my Google calendar did not get reflected in Evolution's version of it, even after triggering a refresh.  I shut down evolution and the source registry and restarted evolution normally, and the calendar's color has stayed the same as I set it to.  (The restart did successfully resync the calendar entries, btw.)

I did not mention it before, I'm sorry about that, when playing with background processes one should restart also all the other in certain order (especially under GNOME Shell, which run the evolution-calendar-factory on its own, whenever it's stopped). That can explain no update of the events of the calendar, maybe.

The debugging itself should add only additional printing, which usually doesn't influence the behaviour, but in case some timing is involved, the debugging can add necessary delays to make things work properly. I remember facing similar issues when trying to debug issues under gdb or valgrind, where especially valgrind slows things down due to all the memory checking, which can avoid issues which are related to "proper timing".

I forgot to ask, should I keep this bug opened? Considering that it cannot be reproduced at the moment...

I'd suggest keeping it open for now.  Heisenbugs that go away when someone looks at them tend to worry the programmer in me :)

Okay, it'll be auto-closed at the end-of-life of Fedora 25 too, unless we happen to find the cause and fix it. I also do not like bugs which happen only "sometimes". They are pretty hard to hunt.

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.