Why does everyone seem to want to develop for the craptastic VDP of the MSX1?

i see many rpg's on msx2 ...

i see many rpg's on msx2 ...

that's the point. RPG's and GFX adventures contributed to the poor reputation of MSX2 gfx modes.
None had investigated about doing somewhat better.. Pratically horizontal smooth scroolling in screen5 was considered almost impossible until someone (thx, ARTRAG) tryed it on an msx2 unfinished game (Total parody)

The same thing also applied on msx1 about smooth scrolling: 'because the hw lack support, this is not possible to achieve'.
Later proof of concept (GNG demo) and games (malaika) proved that under some circumstances it's possible.
But looking at the msx game library you can count less of 10 games featuring smooth scroll, if we exclude the speccy convertions.

The two examples above are effectively (IMHO) a good situation where scrolling maybe difficult. Pratically those games runs at full screen. the amount of data to scroll is huge-
Especially on VK i do not think that this is a very limiting factor.I believe 1 and 2 px scrolls (per frame, meaning 50 or 100 px horizontal scroll per second) are possible using the 'lazy' method (copying 15 bars of the screen, meaning very limited copy instructions during most frames), and possibly more using differential copying although that may have limitations in richness of backgrounds and game code. That's fast enough for most games.

You may call it non-limiting but there must be a reason why a majority of games on C64 and NES were smooth-scrolling whenever they could add that component in the game design, and users of other machines quite consistently mention MSX's lack of scrolling or blocky 8px scrolling as limiting. To date MSX2 didn't do much to show this limit can be overcome while preserving the quality of the game, some individual examples aside.

Seeing that status quo, where MSX2's graphical qualities are assumed to be reached when a game competition produces a static puzzle game as a winner (albeit in screen 8, and a fine game otherwise), I can understand why MSX1 is more the main developer's target.

The two examples above are effectively (IMHO) a good situation where scrolling maybe difficult. Pratically those games runs at full screen. the amount of data to scroll is huge-
Especially on VK i do not think that this is a very limiting factor.I believe 1 and 2 px scrolls (per frame, meaning 50 or 100 px horizontal scroll per second) are possible using the 'lazy' method (copying 15 bars of the screen, meaning very limited copy instructions during most frames), and possibly more using differential copying although that may have limitations in richness of backgrounds and game code. That's fast enough for most games.

About the limited copy instruction on the frame i think it's not a matter of how the vdp is busy.
I've tested spmanbow2 first level with openMSX and a TCL script that show how the vdp is busy during a frame.
during the game we are under the 50% of utilization using the tecnique you mentioned.

The real problem, is, IMHO how interleave those operations with others needed, for example, to simulate an explosion.
this require very well designed code..

I don't recall VK or Contra utilizing software sprites/copies for large explosions so I'm not sure how this would impact the game's design w.r.t. scrolling.
If you're making a Pleasure Hearts or a similar game, yes I agree that would pretty much rule out screen 5. But at such extreme speeds screen 5 graphical details are wasted anyway.
No, they haven't but nemesis series have, tiles that animate slowly .
There is also another game that scroll horizontally in screen5 using vdp copy in a blocky way, but i do not remember the name. Spaceship animations are done with hw sprites, bk with vdp copy.