Not sure I understand;
Why would you change

elseif ($count == 1)
	{
		return array('1');
	}

TO

elseif ($count == 1)
	{
		return array('MORE');
	}

???

This makes no sense to me and it works perfectly as it is for English language (or French or the majority of other languages.)

For example we have these strings:

COM_CHECKIN_N_ITEMS_CHECKED_IN_0="No item checked in."
COM_CHECKIN_N_ITEMS_CHECKED_IN_1="1 item checked in."
COM_CHECKIN_N_ITEMS_CHECKED_IN_MORE="%s items checked in."

or

COM_MENUS_ITEMS_SET_HOME_0="Aucun lien de menu assigné à la page d'accueil"
COM_MENUS_ITEMS_SET_HOME_1="1 lien de menu assigné à la page d'accueil."
COM_MENUS_ITEMS_SET_HOME_MORE="%d liens de menus assignés à des pages d'accueil"

Did not test Slovak but its method looks OK, although there is a small mistake in the code.
(see the red ¿)

If it is true that $count == 3 should be equal to $count == 2, then something does not look right in these strings

COM_BANNERS_BANNERS_N_ITEMS_CHECKED_IN_0="Nebola odomknutá žiadna reklama."
COM_BANNERS_BANNERS_N_ITEMS_CHECKED_IN_1="%d reklama bola odomknutá."
COM_BANNERS_BANNERS_N_ITEMS_CHECKED_IN_2="%d reklamy boli odomknuté."
COM_BANNERS_BANNERS_N_ITEMS_CHECKED_IN_3="%d reklám bolo odomknutých."
COM_BANNERS_BANNERS_N_ITEMS_CHECKED_IN_MORE="%d reklamy boli odomknuté."

I guess this should be checked by the Slovak TT Coordinator.
We will contact him.

BTW, the "issue" you describe above with articles published is just because en-GB simplified their strings. They just have 2 strings:

COM_CONTENT_N_ITEMS_PUBLISHED="%s articles published."
COM_CONTENT_N_ITEMS_PUBLISHED_1="%s article published."

i.e. they do not use COM_CONTENT_N_ITEMS_PUBLISHED_MORE

@infograf768 I agree that in Slovak language pack there are not properly generated plural strings names from Crowdin, and on this basis I have discovered in my opinion this little bug

The bug is not in Joomla code, but in the Slovak pack.
I guess you can close #20003

@infograf768 I am voting for a fix in order to avoid potential problems in the future. Can someone else comment on it? Or then completely remove the line 220 from the code, it makes no sense.

I agree that in Slovak language pack there are not properly generated plural strings names from Crowdin, and on this basis I have discovered in my opinion this little bug

What is wrong with how Crowdin names the strings? It shouldn't actually matter at all how they name it. It's just important that the localise.php matches the generated names.
I agree with @infograf768 that this doesn't sound like an issue with core but an issue within a specific language pack.
Or I don't understand your issue. Going from your original messing around with the localsie.php file, I'd say what you got is expected behavior (JM already explained).

@Bakual

What is wrong with how Crowdin names the strings? It shouldn't actually matter at all how they name it. It's just important that the localise.php matches the generated names.

I think this is what you want to hear about - better plural suffixes in slovak localized files:

COM_CONTENT_N_ITEMS_PUBLISHED_1 for count 1 / Form One on Crowdin, now
COM_CONTENT_N_ITEMS_PUBLISHED_1

COM_CONTENT_N_ITEMS_PUBLISHED_FEW for count 2-4 / Form Few on Crowdin, now
COM_CONTENT_N_ITEMS_PUBLISHED_2

COM_CONTENT_N_ITEMS_PUBLISHED_MANY for count 5-20 / Form Many on Crowdin, in 99% identical to next, may be ignored, now
COM_CONTENT_N_ITEMS_PUBLISHED_3

COM_CONTENT_N_ITEMS_PUBLISHED_OTHERS in 99% cases count over 4 {and in 1% cases count over 20, this may be ignored} / Form Other on Crowdin, now
COM_CONTENT_N_ITEMS_PUBLISHED_MORE

or something like that

I agree with @infograf768 that this doesn't sound like an issue with core but an issue within a specific language pack.
Or I don't understand your issue.

If the "overrided" suffixes obtained from localise.php have not priority to other - then yes, this is not a bug. But I think it is not a good idea.

OK, here's what it looks like is the issue.

With en-GB, if you're aiming to pluralize a string for 3 items, Language::getPluralSuffixes() returns this array:

array(1) {
  [0] =>
  string(4) "MORE"
}

This part is fine. The current behavior is to prepend the pluralized number to the suffixes array, so this is the array that gets looped over:

array(2) {
  [0] =>
  int(3)
  [1] =>
  string(4) "MORE"
}

Meaning in order it will try to use the strings KEY_3 then KEY_MORE. With #20003 applied, this lookup array becomes:

array(2) {
  [0] =>
  string(4) "MORE"
  [1] =>
  int(3)
}

Now the order is KEY_MORE then KEY_3.

Either way I think making this change could be considered a B/C break and shouldn't be considered lightly. But, I can see an argument for both prioritization strategies. To me, since there is already precedent with the existing behavior, the question is if the change has more benefit than keeping the existing behavior (or if the changed behavior has less potential for conflicts, as is apparently the case now).

Just received a message from Drobec ((Slovak TT).
he gives me as example:

eg. 1 = Administrator
2,3,4 - Administratori
5 - Administratorov
10 - Administratorov

Which is indeed what I understood (Please Drobec correct the weird sign in your localise.php)

And I remark again that, if this is what is expected, then

COM_BANNERS_BANNERS_N_ITEMS_CHECKED_IN_0="Nebola odomknutá žiadna reklama."
COM_BANNERS_BANNERS_N_ITEMS_CHECKED_IN_1="%d reklama bola odomknutá."
COM_BANNERS_BANNERS_N_ITEMS_CHECKED_IN_2="%d reklamy boli odomknuté."
COM_BANNERS_BANNERS_N_ITEMS_CHECKED_IN_3="%d reklám bolo odomknutých."
COM_BANNERS_BANNERS_N_ITEMS_CHECKED_IN_MORE="%d reklamy boli odomknuté."

is wrong. Because 2 and 3 should be the same.

Is there anything left to do here or can it be closed?

It seems that the majority vote for maintaining the original state ...